Test Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, unchanged. infinitytracking/test-bundle remains a Symfony 2 bundle, not a Laravel package. Its entry point is the Symfony kernel/bundle registration model (AppKernel::registerBundles(), DependencyInjection/*Extension, YAML/XML service definitions), and its test base classes extend Symfony\Bundle\FrameworkBundle\Test\KernelTestCase / WebTestCase. Laravel has no bundle lifecycle; the equivalent seams are service providers, facades, the Illuminate container, and Illuminate\Foundation\Testing\TestCase. There is no shared contract to bridge — the two harnesses bootstrap different kernels, different environment files, and different HTTP simulation layers. v1.0.1 touches none of this.

Integration feasibility — low, and marginally worse than before. Composer resolution remains the blocker: a bundle targeting Symfony 2.x constrains symfony/framework-bundle, symfony/http-kernel, and PHP to ranges incompatible with Laravel 10/11 (Symfony 6/7 components, PHP 8.1+). The v1.0.1 change — "Update phpunit to 5.7" — narrows the conflict surface rather than widening it: the package now explicitly pins phpunit/phpunit to the 5.7 line, which supports PHP 5.6–7.x, was released in 2017, and left security support in February 2019. Our suites run PHPUnit 10/11 (or Pest 2/3), so the require-dev constraint is a hard composer why-not conflict against our own test runner, not just against Symfony. The only viable path remains cherry-picking individual helper classes out of the tarball.

What v1.0.1 actually tells us. It is a single-commit, version-only bump: no new features, no deprecations, no API changes, no CVE remediation, no Symfony constraint relaxation, no PHP 8 support. Read as a maintenance signal, it says the maintainer is nudging a dependency floor within a dead branch — not modernising the package. It also, usefully, confirms rather than corrects our earlier read: the codebase was already written against PHPUnit 4/5-era APIs (getMock(), string-match assertContains(), setUp() without return types), and 5.7 does not change that. Any residual hope that this package was quietly tracking modern PHPUnit is now closed.

Technical risk — high, marginally reduced on one axis, unchanged elsewhere. The bump does demonstrate a live maintainer with commit access and a tagging habit, which is a small positive versus total abandonment — it slightly lowers the "bus factor zero" concern. It does nothing for the rest: zero stars, zero dependents, opportunity score 14.91, overall score 0.06, no downstream validation anywhere. We would still be the first integrator. Unpatched Symfony 2 and PHPUnit 5.7 code both carry known advisories; composer audit against a forced install is still likely to fail our supply-chain gate, and a PHPUnit 5.7 dev dependency is itself an audit finding in most configurations.

Key questions.

• What is the license, and does it permit vendoring individual helper files into our own tests/Support namespace?
• What is actually inside — substantive reusable logic (fixture loaders, data providers, assertion helpers) or a thin wrapper around Symfony's WebTestCase with no transferable value?
• Is the bundle a fork/derivative of a better-maintained package (e.g. a Liip-style functional test bundle), which would let us adopt upstream instead?
• What specific gap in our current Laravel test setup are we closing — fixtures, HTTP assertions, database isolation, or conventions?
• Does the v1.0.1 composer.json pin phpunit/phpunit to ~5.7 only, or does it also carry a php floor and Symfony ranges that make even a partial extraction of non-test-runner helpers impossible?
• Has anyone run composer why-not / a dry-run install since v1.0.1 landed, to confirm the conflict is now against PHPUnit as well as Symfony?
• Why was PHPUnit bumped in isolation — is there a roadmap (Symfony 3/4, PHP 7.4+) behind it, or is this the last commit before the repo goes quiet again?

Integration Approach

Stack fit — none at the bundle level; partial at the pattern level. Treat this as a reference implementation, not a dependency. "Structured test implementation and helpers" maps cleanly onto a Laravel-native package we own: a base TestCase extending Illuminate\Foundation\Testing\TestCase, traits for database/fixture setup, and Pest uses() bindings — all natively supported.

Migration path (recommended: reject-and-rebuild, optionally vendoring).

1. Vendor the ideas, not the code. If the license permits, copy isolated helper classes into tests/Support/ under an internal namespace, so they never appear in require-dev and are trivially removable.
2. Rewrite base classes. Any class extending a Symfony KernelTestCase must be re-parented to Illuminate\Foundation\Testing\TestCase (or Orchestra\Testbench\TestCase for package development), with createApplication() replacing the Symfony kernel bootstrap.
3. Replace framework coupling. Symfony container lookups become app() / resolve(); Symfony HTTP client assertions become $this->get(), assertStatus(), assertJson*(); fixtures become model factories or seeders.
4. Re-baseline assertions. Port custom assertions to PHPUnit 10/11 signatures and Pest expectations — do not carry over any 5.7-era mocking or assertion idioms.

Compatibility. Non-negotiable targets: PHP 8.2/8.3, PHPUnit 10/11 or Pest 2/3, Laravel 10/11, Symfony 6/7 pulled transitively rather than declared. Anything requiring symfony/symfony ~2.x, phpunit/phpunit ~5.7, or PHP < 8.0 is out. Verify vendored code contains no mcrypt, each(), create_function(), or other removed PHP APIs.

Sequencing.

1. Spike (≤2 days): license audit, composer install dry-run in a throwaway container post-v1.0.1, source read-through, inventory of genuinely reusable helpers.
2. Decision gate: if the reusable surface is under ~200 lines of logic, close it out — port cost exceeds value.
3. Prototype the Laravel-native equivalent on a branch, behind a dev-only autoload entry.
4. Prove parity against the existing suite; require green CI before merge.
5. Record an ADR documenting why we did not depend on the upstream bundle, and cite v1.0.1 as evidence that maintenance is dependency-floor nudging rather than modernisation.
6. Publish internally with usage docs and a deprecation path.

Operational Impact

Maintenance — we own it 100%. v1.0.1 slightly softens "dormant" but not "unmaintained in any way that helps us": a PHPUnit 5.7 bump provides no PHP 8 support, no Symfony upgrade, no security posture. There is no realistic prospect of a PHP 9 release or a CVE fix. Every integration hour is amortised over our own codebase forever. By contrast, pestphp/pest, orchestra/testbench, mockery/mockery, and fakerphp/faker are actively maintained and cover the same problem space.

Support — effectively zero. With 0 stars and 0 dependents there is no community, no Stack Overflow corpus, and no issue-tracker history to search. One recent commit does not create an SLA. Engineers debugging this will read unfamiliar Symfony 2 idioms with no external reference — negative knowledge transfer.

Scaling — technically fine, organisationally not. Test helpers are require-dev-only and never touch production runtime, so there is no latency or availability concern. The scaling risk is CI: forcing a Symfony 2 tree and a PHPUnit 5.7 pin into composer.lock bloats install times, widens the vendor diff, and creates resolution thrash whenever any transitive package bumps a Symfony or PHPUnit constraint. The v1.0.1 pin makes that thrash strictly more likely, since our own PHPUnit major is now a declared conflict rather than an implied one. If vendored, the footprint stays at a few files and scales without issue.

Failure modes to design against.

• Hard stop: Composer refuses to resolve against Laravel's Symfony 6/7 constraints — and now additionally against our PHPUnit 10/11 requirement. CI breaks on composer update.
• Silent drift: PHPUnit 10 incompatibilities cause tests to be skipped or fatally error at class-load time rather than failing loudly; guard with a smoke test asserting the base class is instantiable.
• Supply-chain gate: composer audit flags EOL Symfony and/or PHPUnit 5.7 advisories and blocks the pipeline.
• Upgrade cliff: the next Laravel or PHP major forces removal under time pressure if the code is spread across the suite — mitigate by isolating everything behind one namespace and one base class.
• False reassurance: a 1.0.1 tag may read to stakeholders as "actively maintained"; correct that perception explicitly in the ADR so nobody re-litigates this next quarter.
• Phantom coverage: helpers that auto-skip on missing fixtures can produce green builds with unexecuted assertions; require coverage thresholds on ported helpers.

Ramp-up — negative ROI. No README depth, no examples, no external tutorials, and the v1.0.1 notes are a single changelog line. A Laravel engineer must learn Symfony 2's kernel/container/testing model to read code they will then delete, and must additionally reason about PHPUnit 5.7 semantics that no longer exist in our toolchain. Realistic ramp-up is days for a small helper set, versus hours to write the Laravel-native equivalent from scratch.

TPM recommendation — hold the previous decision; v1.0.1 does not change it. A single-commit PHPUnit bump moves a dependency floor on a dead branch, adds a second composer conflict, and leaves every architectural, security, and support concern intact. Do not add this as a dependency. Sponsor a short spike to mine it for ideas if the license and helper inventory justify it, then ship a small internal test-support package built on Pest/PHPUnit and Testbench — owned by us, upgradeable, and aligned with the stack. Re-evaluate only if upstream ships Symfony 4+/PHP 8 support or an actual feature release.