Phpunit Tia Laravel Laravel Package

Technical Evaluation

Architecture fit

• fruitcake/phpunit-tia-laravel is a Test Impact Analysis (TIA) layer for PHPUnit that records per-test code coverage once, then uses git diffs in CI to run only the tests whose covered lines changed. It is a developer-productivity/CI-cost tool, not a runtime dependency — it sits entirely in require-dev and touches no production code path.
• This is the Laravel-flavoured wrapper around the upstream phpunit-tia package. The Laravel-specific value is exactly what v0.1.1 touches: framework bootstrapping (bootstrap/app.php, container/bootstrap boot) is noise for impact analysis, because a change there would otherwise mark the entire suite as affected. v0.1.1's single change (PR #2, "Leave booting the application out of the coverage") is the first correctness-relevant fix in the Laravel integration.
• Fit is strongest for teams with a large, slow Laravel suite (roughly >1,500 tests or >5 min wall clock) where PR feedback latency and CI minutes are a measured pain point. Below that scale, the added CI complexity and correctness risk are hard to justify.

Integration feasibility

• Low friction: a dev dependency, a config file, and two CI steps (a map-generation job on the default branch, and a selection step on PRs). No application code changes.
• Real feasibility blockers to validate before committing: coverage driver availability (pcov preferred for speed; Xdebug otherwise) and whether the team's PHPUnit major version, Pest, and parallel runners (ParaTest) are supported. These are unresolved from the release notes alone.

Technical risk

• False negatives are the dominant risk. TIA's failure mode is silently not running a test that should have run. Unlike a flaky test, this produces green builds with escaped defects. The blast radius is proportional to suite size and to how much dynamic/implicit coupling exists (service container bindings, config-driven behaviour, facades, observers, queued jobs).
• Pre-1.0 maturity. v0.1.1 is a patch one release after v0.1.0, with a single PR. API, config schema, and test-map format can all change without a major-version signal. Treat as experimental.
• Bus factor. Effectively single-maintainer (Barry vd. Heuvel — highly credible in the Laravel ecosystem, but still one person).
• v0.1.1 specifically changes map semantics. Maps generated under v0.1.0 were produced with bootstrap code in coverage. If a stale map survives the upgrade, selection behaviour is inconsistent and non-reproducible. This is a migration hazard, not a defect.

Key questions

1. Which PHPUnit versions, PHP versions, and Laravel versions are supported? Is Pest supported?
2. Does it work under ParaTest / php artisan test --parallel?
3. What is the fallback when the test map is missing, stale, or the coverage driver is unavailable — full-suite run (safe) or silent partial run (unsafe)?
4. How is the test map stored and versioned (artifact cache, keyed by commit/branch), and what invalidates it?
5. What does the maintainer consider the escape rate / soundness guarantee, and is there a documented "conservative mode" that over-selects?
6. Is there a CHANGELOG/SemVer commitment prior to 1.0?

Integration Approach

Stack fit

• Assumes a standard GitHub Actions/GitLab CI pipeline with a cacheable artifact store and a coverage-capable PHP image. Fits cleanly into an existing "unit + feature test" job; no Docker or infrastructure change required.
• Conflicts to check: any existing coverage-merge tooling (phpunit --coverage-* output already configured), and any policy that forbids Xdebug/pcov in CI images.

Migration path

• Add as require-dev with an exact pinned version (e.g. 0.1.1, not ^0.1) given pre-1.0 status.
• Run in shadow mode for 2–4 weeks: generate the map, compute the selected subset, report the selection, but still execute the full suite in the blocking job. This builds an empirical soundness baseline at near-zero risk.
• Only after shadow-mode data shows no missed-test incidents should the reduced suite become the blocking gate, and even then keep a nightly full-suite run on the default branch.

Compatibility

• Pin the package version and regenerate the test map on every upgrade — v0.1.1 makes this mandatory, since the bootstrap exclusion changes what the map contains.
• Verify PHP/PHPUnit/Laravel version constraints against the package's composer.json before pinning; the release note gives no compatibility signal.

Sequencing

1. Spike (1–2 days): install, generate a map on a representative branch, measure map size and generation time.
2. Shadow mode in CI, instrumented to log selected vs. total test counts.
3. Review: quantify CI minutes saved, review any PR where a change touched bootstrap/config and confirm behaviour is now sane post-v0.1.1.
4. Promote to blocking on PRs; retain full-suite nightly + release-branch runs.
5. Re-evaluate at v1.0 or on any minor bump.

Operational Impact

Maintenance

• Low steady-state effort: one pinned dependency and a map-generation CI job. The maintenance cost is in trust — periodically auditing skipped-test decisions rather than in code upkeep.
• Upgrades require map regeneration and a re-run of the shadow-mode validation. Budget a half-day per version bump until 1.0.

Support

• Internal-only tooling; no customer-facing surface. Support burden = answering "why didn't my test run?" during the shadow period. Nominate one owner (typically a platform/dev-experience engineer) to triage selection anomalies.

Scaling

• Map generation cost grows with suite size and is the scaling bottleneck: per-test coverage collection is memory- and CPU-intensive. Mitigate with pcov, sharded map generation, and a dedicated (non-PR-blocking) job.
• Selection quality improves with suite size, so the ROI curve is favourable — but so does the cost of a false negative, so the safety net (nightly full suite) must scale alongside.

Failure modes

• Coverage driver unavailable → must degrade to full suite, not to zero tests.
• Stale or corrupt map → unpredictable selection; enforce map keying by commit SHA plus package version.
• Bootstrap/config-only changes → post-v0.1.1 these no longer nuke the whole map, but should still trigger a broad fallback; confirm this is the intended behaviour rather than over-narrow selection.
• Non-deterministic coverage (time, randomness, env-dependent branches) → selection drift; quarantine such tests to always-run.
• Silent under-selection → escaped defects in production. This is the failure mode that must be owned explicitly, with a documented rollback (delete the selection step, restore full suite).

Ramp-up

• Roughly 1–2 engineer-days to first useful signal; 2–4 weeks of shadow running before the team can make an evidence-based adoption call. Minimal learning curve for developers (no change to how they write or run tests locally).

Recommendation: Worth a low-cost spike given the potential CI-time savings, but do not gate merges on it at v0.1.x. Adopt in shadow mode, pin to 0.1.1, regenerate maps on upgrade, and revisit for production gating at v1.0 or after demonstrated zero-escape shadow data.