Pest Plugin Blade Coverage Laravel Package

Product Decisions This Supports

• Test-suite investment prioritization: Blade coverage data lets PMs quantify how much of the user-facing presentation layer is actually exercised by automated tests. This informs whether to fund QA/test-hardening initiatives or accept risk in view-heavy areas.
• Build vs. buy for coverage tooling: Rather than building bespoke instrumentation for Blade templates (which PHPUnit/Xdebug alone cannot attribute back to .blade.php files), adopting a plugin that integrates into existing Laravel coverage runs keeps engineering effort focused on product features.
• Release-readiness and regression gates: Coverage thresholds for views can become a CI gate, supporting go/no-go decisions on releases where UI regressions are a known risk (e.g., onboarding flows, checkout, dashboards).
• Roadmap scoping for UI-heavy work: When planning redesigns or multi-tenant theming, coverage visibility helps estimate blast radius and the testing cost of view-layer changes before committing to a date.
• Monorepo/multi-package compatibility: Opt-in monorepo support signals viability for organizations consolidating Laravel services or shared UI packages — a factor in platform-consolidation decisions.
• Not a user-facing feature: This is developer tooling; it does not directly ship end-user value, so it should be evaluated as engineering enablement, not as product capability.

When to Consider This Package

Consider adoption when:

• The team maintains a Laravel application with non-trivial Blade view logic (conditionals, loops, partials, components) and wants coverage visibility beyond PHP classes.
• Existing coverage reports show resources/views as uncovered or absent, indicating blind spots in the presentation layer.
• The organization already runs PHPUnit/Pest with coverage drivers in CI and can absorb a plugin without changing the pipeline architecture.
• The codebase layout is standard Laravel (default resources/views) — the default-first configuration keeps onboarding to near-zero effort.
• You operate a monorepo or multi-package setup and need explicit opt-in rather than opinionated defaults that break non-standard layouts.

Look elsewhere or defer when:

• The project is API-only with negligible Blade usage — coverage value is minimal.
• The team lacks coverage infrastructure, or adding a pre-1.0 (v0.1.x) dependency conflicts with stability/dependency-approval policies.
• View logic is already thin by design (presenters/view models, Livewire/Inertia components), so Blade-level coverage adds noise rather than signal.
• You require multi-version Laravel/LTS guarantees or long-term vendor support commitments that an early-stage package may not offer.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost developer tooling addition that closes a measurement gap in our quality reporting. Today we can tell you how well our backend code is tested, but not our user-facing templates. This package makes that visible and lets us set enforceable quality gates — reducing the risk of UI regressions reaching customers without adding headcount or a new platform.

To engineering leads: It's a Blade coverage plugin that plugs into the coverage runs we already have, defaults to the standard resources/views path so setup is essentially zero-config, and supports monorepo layouts via opt-in. It gives per-template coverage attribution that raw PHPUnit coverage can't provide, and it's small enough to evaluate behind a flag in one sprint. Caveat: it's at v0.1.3 — early-stage. Recommend a contained trial in CI reporting mode only (non-blocking) before we make any threshold enforcing.

Recommendation: Approve a timeboxed pilot (one service, reporting-only) to validate signal quality; revisit enforcement and broader rollout once the package stabilizes past 1.0 and we have baseline numbers.