Phpunit Tia Laravel Laravel Package

Product Decisions This Supports

• CI cost and developer velocity trade-offs. This package enables test impact analysis (TIA) for Laravel/PHPUnit suites: instead of running the full test suite on every push, it uses code coverage data to map which tests touch changed files and runs only those. This directly informs decisions about CI minutes spend, PR feedback latency, and whether to invest in test-selection tooling at all.
• Build vs. buy for test selection. Commercial options (e.g., Launchable, BuildPulse-style analytics) and bespoke in-house scripts are the alternatives. A small, MIT-licensed, Laravel-native package is a low-commitment way to pilot TIA before signing a vendor contract.
• Roadmap sequencing for test-suite health. Adoption forces a conversation about coverage quality, test isolation, and suite runtime — often a prerequisite for other quality initiatives (mutation testing, parallelization, trunk-based development).
• Release-specific (v0.1.1): excluding application bootstrapping from coverage collection reduces coverage noise and avoids attributing framework/bootstrap lines to test selection. Practically, this makes the affected-test mapping slightly more accurate and less likely to over-select tests — a quality-of-life fix, not a decision-changing capability. It reinforces that the package is still in rapid 0.1.x iteration.

When to Consider This Package

Adopt when:

• You have a large Laravel test suite (roughly 10+ minutes for a full run) where PR feedback time is a real bottleneck.
• Your team already collects PHPUnit coverage (Xdebug or PCOV) in CI and can afford the coverage-generation step.
• You want a PHP-only, no-vendor-lock-in approach and are comfortable running a pre-1.0 dependency with pinned versions and a willingness to track changelogs.
• You can institute a safety net — periodic or nightly full-suite runs — to catch false negatives inherent to any TIA approach.

Look elsewhere when:

• The suite is small enough that full runs are already fast; the added complexity isn't justified.
• You need vendor support, SLAs, or a stable public API (0.x semver gives no guarantees).
• You're not on PHPUnit (Pest-only setups, or custom runners) or not on a supported Laravel/PHP version matrix — verify compatibility explicitly.
• Your coverage setup is unreliable or your tests are heavily interdependent, which degrades selection accuracy.
• Compliance or safety-critical contexts where any selective test execution is unacceptable.

How to Pitch It (Stakeholders)

For executives: This is a small open-source package that shortens CI feedback loops by running only the tests affected by a change, rather than the whole suite. The upside is faster merges and lower CI spend; the cost is a pre-1.0 dependency and the operational discipline of periodic full-suite runs to guard against missed regressions. Recommend a time-boxed pilot on one repository with measured before/after CI duration and escaped-defect rate before broader rollout.

For engineering: Drop-in PHPUnit integration for Laravel that builds a test-to-code dependency map from coverage and selects tests per change. v0.1.1 cleans up coverage collection by excluding application bootstrapping, slightly improving selection accuracy. Because it's 0.1.x, pin the version, review each release, and pair it with a scheduled full run (nightly or pre-release) as a correctness backstop.