Behat Code Coverage Laravel Package

Product Decisions This Supports

This is not a Laravel package in the framework-integration sense — it is a Behat extension that wraps phpunit/php-code-coverage so that BDD/acceptance scenarios executed by Behat produce standard coverage artifacts. Its PM value is therefore concentrated in one decision space: does our behavior/acceptance layer count toward quality metrics, or is it a black box?

• Test-strategy investment. Coverage data from Behat tells you whether your Gherkin suite actually exercises application code or is a thin HTTP shell over untested internals. That evidence drives the choice between writing more scenarios, refactoring toward unit tests, or consolidating on PHPUnit/Pest.
• Coverage gates and release readiness. Enabling a Behat coverage job lets you set a percentage threshold on acceptance tests specifically, separate from the unit-suite threshold, and block merges when behavior coverage regresses.
• Build vs. buy. The alternative is hand-rolling xdebug_start_code_coverage() / PCOV shims inside Behat hooks and writing your own report serializers. This package gives you that plus maintained compatibility with every php-code-coverage major (v9 through v14), report schema validation in behat.yml, and the --no-coverage bypass — for free under BSD-2.
• Audit and compliance reporting. Clover, Cobertura, OpenClover, HTML, and Serialized outputs mean the same Behat run can feed SonarQube, GitLab/Jenkins coverage visualization, and a certification evidence pack without a second test pass.
• CI cost and runtime decisions. Branch/path coverage via Xdebug is expensive; this package supports PCOV and lets you toggle branchAndPathCoverage, so you can price the difference between "line coverage on every PR" and "full branch coverage nightly."
• Vendor-risk scoping. 62 stars and zero dependents is a signal — but a dev-dependency signal with a bounded blast radius. It informs whether this is allowed in the stack without a formal security review (it should be: test-only, permissive license, no production surface).

When to Consider This Package

Adopt when:

• Behat is already a real part of your Laravel (or any PHP) suite — typically via a Behat + Laravel integration or custom contexts — and those scenarios currently contribute nothing to coverage numbers.
• Your unit/feature layer is thin relative to your behavior layer (common in legacy or freshly-modernized Laravel apps), so acceptance tests are your best available coverage signal.
• You require standard machine-readable artifacts (Clover/Cobertura) for an existing dashboard, and you do not want a bespoke exporter.
• You want multiple report formats from one run (reports key) or branch/path coverage under Xdebug.
• You are on PHP 7.1+ with a supported Behat and Symfony 5/6/7 stack; the release history shows prompt tracking of upstream php-code-coverage majors, which is the main ongoing cost you are outsourcing.

Look elsewhere when:

• The team uses PHPUnit or Pest only. Laravel's default testing stack ships native --coverage; adding Behat purely to obtain coverage is backwards. This is the majority case for Laravel teams and the single strongest reason to say no.
• You need merged coverage across suites (unit + feature + Behat + JS). This package reports Behat in isolation; merging is still your CI's job (phpcov/upstream merge tooling). Budget for that separately rather than assuming this solves it.
• You need runtime/production coverage or request-level tracing — that is APM territory (Xdebug/PCOV plus an observability vendor), not a test-reporting extension.
• You need end-to-end coverage spanning browser JavaScript and PHP — you would need Istanbul/nyc plus a coverage-merging layer.
• Governance requires a named commercial maintainer or a support SLA. This is a single-maintainer, low-star project; the escape hatch is trivial (test-only, replaceable), but it will not pass a "supported vendor" procurement gate.
• You are still on Symfony 4 or older php-code-coverage majors — support was explicitly removed, so you would be pinned to an old branch with no security path.

How to Pitch It (Stakeholders)

For executives (one paragraph): We run behavior-level tests that describe product requirements, but today those tests produce no coverage evidence — we cannot say what percentage of the application they actually exercise. This extension closes that gap for a near-zero cost: it is a test-only, BSD-licensed dev dependency that emits the same coverage reports our CI and code-quality dashboard already consume. It introduces no production code, no runtime risk, and no new toolchain. It lets us put a measurable gate on our acceptance suite and produce audit-ready coverage artifacts, and if the project ever stalls we remove one dependency from a require-dev block.

For engineering (the practical case):

• No new report format to learn: output is php-code-coverage output — the HTML, Clover, and Cobertura files your pipelines and Sonar already parse.
• Configuration lives in behat.yml under a reports key with schema validation, so misconfiguration fails fast rather than producing silently empty reports.
• Operationally considerate: warnings go to stderr, --no-coverage cleanly bypasses instrumentation, PCOV and Xdebug coexisting is handled, and there is a static-analysis cache for repeat runs.
• Coverage driver is your choice (Xdebug for branch/path coverage, PCOV for speed), which keeps the CI time budget negotiable.
• The risk is maintenance cadence, not correctness: the author has tracked upstream majors promptly (v9 → v14) and dropped unsupported Symfony versions deliberately. Pin the version, let Dependabot surface upstream bumps, and treat a missed release as a signal to fork or drop rather than a blocker.