- Does dvdoug/behat-code-coverage work with Laravel?
- It is a Behat extension, not a Laravel package, so it only helps if your Laravel application already has a Behat or Gherkin acceptance suite. There is no service provider, no config publishing and no application code changes: everything is configured through an extensions block in behat.yml. If your team tests with PHPUnit or Pest only, this package adds nothing and you should use the native --coverage and --coverage-clover options instead.
- How do I install and enable behat-code-coverage?
- Install it as a dev dependency with composer require --dev dvdoug/behat-code-coverage, then register the extension under the extensions key in your behat.yml profile along with the driver and the reports you want. Because it wraps phpunit/php-code-coverage, the reports it emits look exactly like PHPUnit's and are accepted by existing CI tooling. Check the documentation at behat.cc for the exact extension class name and the available report, filter and cache options.
- Why is my Behat coverage report empty or showing near-zero coverage?
- Coverage is collected in-process, so Behat scenarios must exercise application code inside the same PHP process that started the Behat run. If your suite drives a separately booted php artisan serve, nginx or php-fpm instance over HTTP, which is the classic Laravel acceptance setup, instrumented lines will barely register and the numbers will be misleading. The old RemoteXDebug driver that solved this was removed in 5.0.0, so you need to bootstrap the Laravel testing kernel inside a Behat context instead. Verify this architecture question before adopting the package.
- Which PHPUnit and php-code-coverage versions does it support?
- Its major versions track phpunit/php-code-coverage majors, with each release documenting the supported range, for example php-code-coverage 14 in 5.4.2, 13 in 5.4.1, 12 in 5.3.7 and 11 in 5.3.3. Because php-code-coverage normally arrives as a transitive dev dependency of PHPUnit, the most common failure is a Composer resolution conflict where your PHPUnit pins one major and the extension demands another. Run composer update early to surface the conflict rather than discovering it mid-sprint.
- Which Laravel and Symfony versions are compatible?
- The package has no Laravel coupling at all; what matters is the Symfony component versions in your dependency tree, which are supported at 6 and 7 (Symfony 4 support was dropped in 5.3.2). That covers Laravel 9, 10 and 11, but Laravel 8 sits on a Symfony 5 floor and falls outside the supported matrix, so it would require an older and unsupported extension release. Check the supported matrix against your composer.lock before committing to the upgrade path.
- Can it fail my build when coverage drops below a threshold?
- No. The extension only generates reports; it does not enforce minimum coverage gates or change Behat's exit code. If you need a hard gate, enforce it in CI with a tool that parses the Clover XML, such as a coverage-checker step or your CI provider's built-in coverage thresholds. Treat the extension purely as a report producer and keep the policy decision elsewhere.
- What report formats can it generate?
- It can emit Clover, Cobertura, OpenClover, HTML, plain text and serialized reports, matching the php-code-coverage output formats developers already consume. HTML is useful for local inspection of uncovered lines, while Clover XML is the standard input for CI dashboards and code quality platforms. You can enable several reports in the same behat.yml block if you want both human-readable and machine-readable artifacts.
- How do I get Behat coverage into Codecov, SonarQube or GitLab CI?
- Configure a Clover report in the behat.yml extension block, then point your CI uploader at the generated XML file just as you would with PHPUnit output. Because the format is the same php-code-coverage Clover schema, existing upload steps and quality gates usually work unchanged. Make sure the report path is inside the workspace your CI job uploads, and cache or remove it between runs if you regenerate it on every pipeline.
- Should I use PCOV or Xdebug as the coverage driver?
- PCOV is significantly faster and is usually the right choice for CI throughput, while Xdebug tends to be more broadly available and is required if you need branch and path coverage, configurable via the branchAndPathCoverage option. Whichever you pick, confirm the extension is actually enabled in your CI PHP image, since a disabled driver is a common cause of silently empty reports. Many teams keep Xdebug off for Behat runs to avoid the runtime penalty.
- Is dvdoug/behat-code-coverage actively maintained, and what are the alternatives?
- It is a small, single-maintainer project with roughly 62 stars and few listed dependents, so the bus factor is one, though the changelog, CI badge, Read the Docs site and BSD-2-Clause licence all point to solid engineering hygiene and it ships upstream-compatibility releases promptly. For dev-only tooling that is usually acceptable, but treat it as a replaceable component with a documented exit plan. The main alternative is to skip it entirely and rely on PHPUnit or Pest native coverage, or to consolidate acceptance coverage into the same PHPUnit process, which removes the dependency altogether.