Laratesto Laravel Package

Technical Evaluation

Architecture fit. ichinya/laratesto is a dev-only test-runner package for Laravel, not a runtime dependency. That materially caps blast radius: it can break a CI pipeline but cannot break production. The v0.8.3 change is confined to test discovery — class-level #[Test] attributes on classes extending LaravelTestCase or using InteractsWithLaravel — which is the package's core adoption path for suite-level (rather than method-level) test declaration. Architecturally this is a good fit for teams already comfortable with PHP 8 attributes and Laravel's package auto-discovery, which the release notes confirm works end-to-end on a fresh Laravel 13 skeleton.

Integration feasibility. High. The published-package verification is unusually thorough for a 0.8.x release: installed from Packagist via ZIP distribution, no path repositories, no platform overrides, no local source substitution, Composer validation and real platform checks passing on PHP 8.3.35, 8.4.26 and 8.5.11. Notably the consumer ran without PHPUnit at all, which confirms the runner is self-sufficient rather than a thin PHPUnit wrapper. The PHP >=8.3 floor is a real but manageable constraint.

Technical risk. Three items dominate:

1. Discovery semantics are load-bearing and subtle. The fix excludes "bridge helper implementations, including trait aliases" while "preserving user overrides, inherited user tests and unrelated methods with matching names." That is a precedence rule with several interacting cases. Getting it wrong in either direction is dangerous: over-exclusion silently drops tests (CI stays green, coverage quietly falls), over-inclusion produces duplicate or spurious runs. The added native CLI regression test is the right mitigation but one regression test is thin coverage for a rule this conditional.
2. Pre-1.0 versioning. At 0.8.3 there is no semver stability guarantee. Discovery behavior and attribute APIs can still shift before 1.0, and this release itself demonstrates that — it changes which tests are found.
3. Dependency ceiling. nette/schema caps PHP at 8.5, so PHP 8.6 is non-blocking-failing. This is an inherited constraint, not introduced here, but it becomes your constraint too once you adopt the package.

Key questions. What is the supported Laravel version matrix beyond the verified 13.37.0? Is there a documented, stable contract for discovery precedence, or is it defined only by tests? What is the 1.0 timeline and the intended semver policy at and after 1.0? Does the package coexist with an existing PHPUnit suite in the same repo, or is it a replacement? What is the maintainer bus factor and is there any commercial support path? Are the bundled Agent Skills a versioned, supported surface or incidental documentation?

Integration Approach

Stack fit. Strong for Laravel shops on PHP 8.3–8.5 that want attribute-driven, low-ceremony test declaration. Weak fit for organizations standardized on PHPUnit or Pest as a mandated, audited runner, or those already planning a PHP 8.6 upgrade.

Migration path. Do not convert a suite wholesale. Sequence:

1. Spike on one low-risk service. Add as a require-dev dependency pinned to exactly 0.8.3 (not ^0.8) — pre-1.0 caret ranges are unsafe here.
2. Parity gate. Record the test count and coverage percentage before and after enabling class-level discovery. The release notes themselves show counts shifting between unit/Laravel runs (106 passed / 2 skipped; 119 passed / 1 skipped) — expect your numbers to move, and require an explicit explanation for every delta before proceeding.
3. Targeted regression. Add your own tests that assert discovery behavior for trait aliases and inherited user tests in your codebase. Do not rely solely on upstream's single CLI regression.
4. CI matrix across PHP 8.3, 8.4 and 8.5 with real coverage enabled, mirroring upstream's validated configuration.
5. Broaden only after step 2–4 pass on two independent services.

Compatibility. Verify your Laravel version explicitly rather than assuming; the release only evidences Laravel 13.37.0. Confirm no collisions if the repo also runs PHPUnit or Pest. Treat PHP 8.6 as out of scope until the nette/schema constraint lifts.

Sequencing relative to 1.0. Given the pre-1.0 status, treat this as a bounded pilot, not a standards decision. Re-evaluate at 1.0 when the discovery contract and semver policy should be settled — that is the natural point to make it the default.

Operational Impact

Maintenance. Low steady-state cost: dev-dependency bumps in Composer, no runtime surface, no infrastructure. The real cost is governance — test infrastructure is a shared team asset, so upgrades deserve the same change management as production dependencies, particularly any release that touches discovery.

Support. Community/individual-maintainer profile, no SLA. The bilingual (English/Russian) documentation and verified source-checkout examples are a genuine positive, but they don't substitute for a support contract. Mitigation: keep tests written in a portable style so a fallback to plain PHPUnit is a runner swap, not a rewrite. Validate that assumption during the pilot.

Scaling. Fine for many suites; the constraints are ordinary CI ones — wall-clock time, memory, and parallelism. Watch for growth in skipped-test counts, since skips are the most common way a discovery regression hides.

Failure modes, ranked by severity:

• Silent non-discovery — tests stop being collected, the suite still passes, coverage erodes unattended. The single most dangerous failure and the one v0.8.3 is directly touching. Detect with a test-count floor assertion in CI, not just a pass/fail gate.
• Over-exclusion of user overrides — the fix explicitly preserves user overrides; verify yours are actually preserved rather than trusting the changelog.
• Trait alias ambiguity — the "bridge helper implementations, including trait aliases" rule is the least self-evident part of the change; probe it with your own fixtures.
• PHP version ceiling — CI breaks on 8.6 when the organization mandates it; the failure is loud, which is the good news.
• Generated-test drift — bundled Agent Skills lower the cost of producing tests, which raises the risk of large volumes of low-value or near-duplicate tests entering the suite. Put generated tests behind normal review.

Ramp-up. Modest. Engineers fluent in PHPUnit attributes will be productive quickly; the class-level #[Test] idiom is a small conceptual step. Budget a half-day per team plus the pilot's parity work. The larger ramp-up risk is institutional knowledge of the discovery rules — if only one engineer understands why a given test is or isn't collected, that's the operational weak point to write down before scaling adoption.