Pest Plugin Coverage Laravel Package

Product Decisions This Supports

• Release quality gates. Any "no merges below threshold" policy needs a machine-readable coverage number produced inside CI. This plugin was the bridge between the Pest runner and PHPUnit's coverage engine, so a PM decision to gate releases, hotfix branches, or revenue-critical modules on coverage depends on that plumbing existing — and in current Pest it ships free with the framework itself.
• Build vs. buy vs. "already have it." The recurring PM question with test tooling is whether coverage is something we build, buy as a hosted service (Codecov, Coveralls, SonarQube), or inherit from the framework. This package sits in the "inherit" bucket, which makes it a decision about avoiding a bespoke dependency rather than acquiring one.
• Roadmap inputs for engineering health. Coverage trend lines, per-module attribution, and "untested surface area" reporting are all downstream of the same primitive. If coverage data isn't collected at all, none of those roadmap items are estimable, let alone buildable.
• Prioritization and risk scoring. Coverage per module lets you argue for refactor budget with data instead of anecdote — ranking the highest-risk areas before a Laravel major upgrade, a monolith split, or a team handover. Coverage becomes a risk input, not a vanity metric.
• Use cases that justify the work: legacy app stabilization, pre-migration baselines, onboarding a team to TDD with fast visible feedback, and locating dead or unreachable code no test exercises.

When to Consider This Package

Adopt only in a narrow, temporary case:

• You are pinned to an older Pest 1.x codebase that predates native coverage support, and upgrading the framework is not feasible this cycle.
• You need a stopgap for one or two releases and explicitly accept ownership of the fork. MIT licensing and a tiny surface area mean low legal friction — but low legal friction is not a reason by itself.

Look elsewhere in essentially every other case:

• Default answer: do not adopt. The repo is archived, has 9 stars, and zero dependents. No security patching, no PHP/Laravel/Pest compatibility guarantees, no community signal that it behaves correctly on the versions we'll run six months from now. An archived dependency is a liability with an expiry date, not an asset.
• On Pest 2.x/3.x, coverage is a first-class runner flag (pest --coverage, --min, --coverage-clover). Use the framework; adding an archived plugin to recreate core functionality is pure downside, and can actively conflict with native flags.
• If you need coverage outside the Pest ecosystem, use PHPUnit + php-code-coverage directly — or a hosted service if what you actually want is PR annotation and trend history rather than a local number.
• If the underlying goal is defect detection rather than line execution, coverage is the wrong instrument. Mutation testing (Infection) or static analysis (PHPStan/Larastan) answers that question.

How to Pitch It (Stakeholders)

For executives — framed as a savings: An archived third-party plugin surfaced in our dependency review. It's a small, MIT-licensed connector that reports how much of our code our tests actually exercise. It has single-digit stars, zero downstream users, and no maintainer — so the recommendation is not to adopt it. The good news: the capability it represents is already free, because our test framework reports coverage natively. What's worth a decision is the policy around it — a coverage delta required on merged PRs and a coverage ratchet on our three to five riskiest modules. That's a process commitment, not a procurement: no new dependency, no added maintenance surface, and it turns an engineering-health aspiration into a measurable gate.

For engineering — the practical version: Do not add pestphp/pest-plugin-coverage to composer.json. It's archived with negligible adoption, and the maintenance cost transfers to us the first time PHP or Pest moves a minor version. Use Pest's built-in coverage driver (or PHPUnit directly) and wire --min into CI through a Composer script so local and pipeline runs are identical. If we're genuinely stuck on Pest 1.x, the roadmap item is the framework upgrade, not a vendor pin to a dead plugin — treat any current usage as technical debt with a dated removal ticket, since Composer's abandoned-package audit will flag it in governance reviews anyway. And let's resist chasing the repo-wide percentage: a ratchet on the modules that actually hurt when they break will buy more confidence per hour of engineering time than a global number ever will.

One-line ask: Approve the policy (coverage gates on risk modules, built-in tooling only), decline the dependency.