Product Decisions This Supports

Quality-gate enforcement in Laravel CI: Add a coverage threshold step to GitHub Actions, GitLab CI, or Forge deploy pipelines so merges fail when line/method/class coverage drops below agreed targets.
Tiered standards by code criticality: Enforce different thresholds for app/, packages/, or domain modules—for example, 95% line coverage for billing logic and 80% for utility code—without buying a platform.
Build-vs-buy decisions: Replace ad hoc shell scripts or custom PHPUnit parsers with a small MIT-licensed CLI, avoiding SonarQube/Coveralls-level spend when the team only needs a pass/fail gate.
Test-debt prioritization: Use failing-file output to identify under-covered directories and feed roadmap discussions on refactoring, legacy stabilization, or test investment.
Release readiness and risk management: Treat coverage thresholds as a release criterion for Laravel services where regressions are expensive, while keeping the check lightweight and developer-owned.
Adoption/pilot scoping: Use directory filtering to pilot the gate on high-risk modules first, then expand once developers trust the signal and CI runtime impact is understood.

When to Consider This Package

Adopt if:
- Your Laravel application uses PHPUnit and can generate --coverage-php reports in CI.
- You need a simple, deterministic pass/fail gate on line, class, or method coverage, including per-directory thresholds.
- You want a CLI-first, low-operations tool compatible with Symfony/PHPUnit Bridge versions used in modern Laravel stacks.
- Your team values fast feedback and actionable failure output—such as a list of files below threshold—over dashboards.
- You are willing to pin a dev dependency and own a small CI configuration change.
Look elsewhere if:
- You need historical trends, PR annotations, dashboards, or coverage badges as a managed service; consider Codecov, Coveralls, or SonarQube.
- You need static analysis, duplication, complexity, or mutation testing; pair with PHPStan, Psalm, or Infection instead of treating this as a full QA platform.
- Your tests are not driven by PHPUnit or you cannot produce PHPUnit coverage reports.
- You require dynamic per-PR thresholds, context-aware policies, or organization-wide quality reporting.
- You have a very large monorepo where parsing coverage files could materially slow CI, unless you cache reports or scope checks by directory.
- Vendor-risk tolerance is low: the project is small and has limited adoption, so plan for version pinning and a fallback custom script if maintenance stalls.

For executives: “This is a low-cost quality guardrail for our Laravel codebase. It blocks merges that drop below agreed coverage thresholds, focusing first on business-critical modules. It is MIT-licensed, requires minimal setup with our existing PHPUnit tests, and avoids a commercial QA platform. Success can be measured by fewer coverage regressions, faster review decisions, and targeted test investment in the riskiest areas.”
For engineering: “We’ll add handcraftedinthealps/code-coverage-checker as a dev dependency, generate a PHPUnit coverage report, and run it as a CI step. Example: vendor/bin/code-coverage-checker coverage.php line 90 app/. It supports line/method/class thresholds and directory filters, fails fast with files below target, and fits existing GitHub Actions/GitLab CI workflows. Pilot it on app/Domain or another high-risk area, pin the version, and revisit if we later need dashboards or trend reporting.”