Download the PHP package capell-app/pest-plugin-blade-coverage without Composer

Pest Blade Coverage

Pest plugin for checking that Laravel Blade views are rendered by your test suite.

Normal PHP coverage never reports resources/views/**/*.blade.php, because Blade compiles to PHP elsewhere before it runs. This plugin fills that gap: it records the views Laravel actually renders during your tests, then compares uncovered views against a committed hash baseline so CI only fails for new or changed uncovered Blade files.

It works out of the box on a standard Laravel application (resources/views), and a single include entry extends it to package-per-directory monorepos.

Install

If the package is not available through Packagist yet, add a VCS repository first:

Configure

Configuration is optional. With no tests/blade-coverage.php the plugin scans resources/views/**/*.blade.php, so it works out of the box on a standard Laravel app.

To customise, create tests/blade-coverage.php:

Monorepos

For a package-per-directory monorepo, add the package views to include (the auto grouping then labels failures by package name):

Add a Composer script:

Usage

Run the check:

Create or refresh the baseline:

The baseline update command refuses to write a baseline when target views exist but no views were rendered. This usually means the selected tests did not exercise Blade output. If that is intentional, use the explicit override:

Use a custom config path:

Write a machine-readable report for CI summaries or annotations:

Coverage Rules

• A Blade file is covered only when Laravel renders it.
• Included partials and component views count because Laravel renders them.
• Reading a Blade file with file_get_contents() does not count.
• Existing uncovered views are allowed only while their content hash matches the baseline.
• New uncovered views and changed uncovered views fail the run.
• Parallel Pest runs are supported through JSON shards in the configured cache directory.

Ignoring Individual Views

Add the ignore marker inside a Blade file (typically as a comment) to drop it from coverage entirely, without touching exclude globs:

Co-locating the marker keeps the decision next to the view, so it survives moves and renames that a path-based exclude would not.

Failure Policy

• Baseline (default): new and changed uncovered views fail; baseline-matched uncovered views are allowed.
• Strict ('mode' => 'strict'): the baseline is ignored and any uncovered view fails. Good for a green-field package that should keep 100% of views rendered.
• Minimum coverage ('min_coverage' => 90): additionally fail when the covered percentage drops below the threshold. Combines with either mode.

GitHub Actions Integration

When the run detects GitHub Actions (GITHUB_ACTIONS=true) it automatically:

• emits ::error workflow-command annotations for each new/changed uncovered view, so they appear inline on the pull request diff, and
• appends a coverage summary table to $GITHUB_STEP_SUMMARY.

No extra flags are required; it is a no-op outside of GitHub Actions.

Programmatic Use

Capture the views a code path renders from within a single test, independent of the suite-wide run:

Failure Examples

If you add a Blade file but no test renders it:

This fails the Pest process with exit code 1.

If a Blade file was already baseline-uncovered and its contents change without adding render coverage:

This also fails with exit code 1. Fix either case by adding a test that renders the view through Laravel, or by deleting the Blade file if it is genuinely unused.

Baseline Format

The baseline stores uncovered views by normalized path and content hash. It also stores the include/exclude fingerprint so the run can warn when the configuration has changed since the baseline was generated (re-run with --blade-coverage-update-baseline to refresh it). The warning is informational and does not change the exit code:

Older baselines that contain only a path-to-hash object are still supported.

Publishing To Packagist

This package is ready for normal Composer distribution once the GitHub repository is public and tagged.

1. Log in to Packagist.
2. Open Submit Package.

3. Enter the public repository URL:

4. Submit the package. Packagist reads the package name from composer.json.
5. Enable the GitHub/Packagist hook when prompted so new tags update immediately.

After Packagist accepts it, consumers can remove the Composer repositories VCS entry and install the package normally: