jasonmccreary/phpunit-tia
phpunit-tia brings Test Impact Analysis to PHPUnit: it tracks which tests cover which code, then runs only the tests affected by your uncommitted changes. Skip the full suite, get faster feedback, and keep confidence in your changes.
Basis of assessment: the supplied data set is empty, so this evaluation is derived from the v0.5.0 release notes and the package's established role as a PHPUnit test-impact-analysis (TIA) tool. Items marked as questions require verification against the repository before adoption.
Architecture fit. phpunit-tia is a development-only PHPUnit extension that records a source→test dependency graph on a full test run and replays only the tests affected by a change. This fits Laravel/PHP cleanly: Laravel's test suites are PHPUnit-based, and Pest runs on top of PHPUnit, so no application code changes are required and there is no production runtime footprint. The architecturally significant change in v0.5.0 is #24 ("Explicit edges and integration API") together with #27 and #26: the package now exposes a queryable contract (testsLinkedTo(), index-by-source, "every known test file") rather than only a runner behaviour. That moves it from an opaque CLI flag to an embeddable engine that CI scripts, IDE watchers, monorepo tooling, and custom runners can consume.
Integration feasibility. Low-friction: Composer require-dev entry plus extension registration in phpunit.xml, with the graph persisted as a CI cache artifact. v0.5.0 removes two blockers that previously made integration risky: graph recording under ParaTest (#28) unblocks php artisan test --parallel, and treating configured group selection as a full run (#22) removes a class of incorrect partial replays. #25 (summarising affected test files on every run) is the enabler for a safe shadow-mode rollout, since it makes the tool's decisions observable without changing what executes.
Technical risk. The dominant risk is false negatives — a skipped test that would have failed, producing a green build over broken code. Two of the seven changes (#21 "never replay without a recorded baseline", #22 group selection) are precisely this failure class, which is good responsiveness but also evidence that correctness is still being hardened. At 0.5.0 the package is pre-1.0 and semver permits breaking changes in minor bumps. Treat the graph as a cache with correctness implications, not a pure performance optimisation.
Key questions.
composer.lock, phpunit.xml, PHP version, and TIA version?--filter, and --group usage in existing scripts?Stack fit. Laravel 9–11 with PHPUnit 10/11; Pest assumed compatible via PHPUnit. Install as a pinned dev dependency (0.5.0 exact, not ^0.5) given pre-1.0 churn. Register the extension in phpunit.xml and add the graph directory to the CI cache with a key derived from lockfile + config + package version.
Migration path. (1) Local spike on one representative application — record a baseline from a fully green full run. (2) Shadow mode in CI: continue running the full suite, but capture and diff the #25 summary (affected files) against the tests that actually changed; this is the only credible way to build confidence in edge coverage. (3) Enable replay for pull-request pipelines only, keeping full runs on main and nightly. (4) Expand to release branches once drift is zero over several weeks.
Compatibility. Audit existing CI invocations for --group, --filter, and --parallel before enabling. Note the deliberate trade-off in #22: teams relying on group filters will silently fall back to full runs — correct, but it means CI time savings may not materialise and should be measured, not assumed. Verify no collision with existing PHPUnit extensions or listeners.
Sequencing. Baseline recording must be a separate, deliberate step from enabling replay; never introduce the package and turn on replay in the same change. Land shadow mode first, enforce second, and keep the nightly full run permanently as the correctness backstop.
Maintenance. Small surface area — a dev dependency with a config stanza and a cache artifact. The real maintenance load is upgrade discipline: pin the version, review changelogs for correctness fixes, and schedule upgrades deliberately rather than floating the constraint.
Support. Single-maintainer open-source project with no SLA and a bus factor of one. Acceptable for developer-productivity tooling; unacceptable as a hard gate on anything compliance- or release-critical without an internal owner who can debug the graph. Budget roughly a named owner and a documented rollback ("disable the extension, run full suite").
Scaling. Benefit scales with suite size and change locality: large suites with many small PRs see the biggest wins; broad refactors invalidate large portions of the graph and degrade toward full runs. Parallel execution is now supported for recording, but parallel replay behaviour and per-worker consistency should be validated under load before relying on it.
Failure modes.
Ramp-up. Roughly half a day for the spike and CI wiring, plus one to two sprints of shadow-mode observation before enforcement. Team education should cover what the graph does and does not model, and an explicit norm that CI failures are never debugged by disabling TIA without recording why.
How can I help you explore Laravel packages today?