Autotest Bundle Laravel Package

Technical Evaluation

Architecture fit. Unchanged. mano/autotest-bundle remains a Symfony bundle, registered via Symfony's Bundle class and DependencyInjection extension, hooking the Symfony Router and PHPUnit bridge. A Laravel application will still resolve it in Composer and still boot nothing. The v1.1.2 change — "alter resolver interface to return route decorator" — is internal plumbing inside that Symfony-specific resolver chain; it does not introduce a framework-agnostic entry point, a Laravel service provider, or a portable data provider. The concept remains portable and valuable; the artifact remains non-adoptable.

Integration feasibility. Still low as a direct dependency, but the release note modestly improves feasibility as a design reference. The introduction of a route decorator abstraction is the single most useful thing in the package for our purposes: it implies the resolver's output is a normalized, wrapped route object (path, verbs, parameters, likely metadata) rather than a raw framework route. That is precisely the seam we would need to reproduce for a Laravel harness — it reduces the "read the source and guess the invariants" portion of the spike. It does not reduce the 1–2 day build estimate materially; it sharpens the design we copy.

Technical risk. Revised in two directions.

• Downward (positive): the abandonment finding must be softened. A release after ~3 years contradicts "no maintenance path" and is a genuine, if thin, signal of a living maintainer. We should re-verify the release date, changelog, and Composer constraints rather than assume them — but "last release 2022-02-17" is no longer accurate.
• Upward (negative): changing a resolver interface's return type is a breaking change to a public extension point, shipped as a patch version (1.1.2). Under semver this is at minimum a minor-with-deprecation, arguably a major. Two readings, both bad for us: either the maintainer does not track semver discipline (so any future minor can break our fork-of-record), or the interface is not considered public (so there is no stability guarantee on the thing we would most want to copy). Neither is disqualifying for a pattern, but it settles the question of whether to pin to the upstream artifact.
• Unchanged, still high: no dependents, three stars, no support corpus; and the blast radius of the harness itself — auto-generated route tests execute real endpoints and will mutate state, fire jobs, send mail, or trip limiters if run against a non-isolated environment. A route decorator layer arguably increases this surface, since decorated routes are more likely to be dispatched faithfully (correct verbs, real parameters) rather than safely defaulted to GET.

Key questions. Prior questions stand; the release adds:

1. Is the resolver interface documented as public API? If yes, the version bump is a semver violation — evidence of release-process risk. If no, there is no contract we can rely on for a fork.
2. Does the route decorator carry HTTP verbs, required parameters, and middleware/auth metadata, or is it purely a presentation wrapper? If it carries verbs and parameters, the porting spike gets shorter and the resulting Laravel harness gets more accurate — this is the question worth half a day.
3. Do the decorator's methods make it cheap to substitute path parameters and expected status sets externally, or is substitution still baked into the resolver?
4. Has the Composer constraint set been widened alongside this change (Symfony 6.4/7.x, PHP 8.2+)? A functional change without a platform-support change does not help a modern estate.
5. Who owns the fork if we take one? Unchanged, and now more pointed: an upstream that breaks interfaces in patches is an upstream we track by diffing, not by upgrading.

Integration Approach

Stack fit. Unchanged: not applicable as a Laravel dependency. Treat as a pattern to be reimplemented. Note the v1.1.2 diff as a reading assignment, not a dependency — the decorator shape is the part of the design worth lifting.

Migration path. Sequence holds, with one insertion:

1. Spike (0.5 day, now slightly better value). Read the resolver and the new route decorator. Extract invariants: every registered route is dispatchable; no route returns 5xx; no route throws an unhandled exception. Capture the decorator's field set as the schema for our own normalized route object.
2. Build in-house (1–2 days). Laravel command + PHPUnit data provider over Route::getRoutes(), filtered by middleware group, path parameters substituted from fixtures, dispatched via actingAs() + call(), asserted < 500 against an explicit expected-status set. Adopt the decorator idea — model each route as a value object carrying verbs, middleware, parameters, and expected statuses — because that is what makes the harness testable in isolation.
3. Gate it (0.5 day). Dedicated test DB, Queue::fake(), Mail::fake(), Http::fake(), maintenance-mode guard. Non-negotiable given the decorator makes dispatch more faithful.
4. Do not track upstream. Record v1.1.2 in the evaluation log, archive the reference, and move on. If we ever fork, pin to a commit hash and diff deliberately — the patch-level interface break means no upgrade path is safe by default.

Compatibility. Still assume incompatibility with Symfony ≥ 6.3 and PHP ≥ 8.1 until the composer.json is read directly. The v1.1.2 note says nothing about platform support, which is itself informative: a functional change with no accompanying constraint widening suggests the package is being maintained for its author's environment, not for the ecosystem. Do not --ignore-platform-reqs.

Sequencing. Unchanged. Land the in-house harness after a stable route inventory and before broad end-to-end investment. Run it as the fast first gate on every PR; keep feature tests as the deeper layer; do not let it substitute for authorization or contract testing.

Operational Impact

Maintenance. As a dependency: still unowned upstream, still no release cadence we can plan against — and the v1.1.2 patch-level interface change means even a pinned minor is not a safe upgrade unit. As a fork or in-house build: ~200–400 LOC of test scaffolding, 2–4 hours per quarter to track Laravel majors and router API changes, unchanged. Bounded and acceptable, provided a named owner exists.

Support. No vendor, no SLA, no community. Three stars, no dependents. The 2025-era release slightly reduces the "dead repo" risk but does nothing for support: a single maintainer responding on their own schedule is not an escalation path. Budget for the team to be the maintainer from day one.

Scaling. Unchanged on both axes. Route count: linear dispatch is fine at 50, slow at 2,000 without filtering and parallel execution. Statefulness remains the dominant risk — each write endpoint increases cross-test contamination probability, and a decorator that dispatches verbs and parameters faithfully raises the chance of actually hitting destructive routes. Transactional wrapping plus fakes is the mitigation, not an optimization.

Failure modes.

• False negative: auth middleware redirects everything to 302/200; genuine 500s on the authenticated path go undetected.
• False positive: rate limiters, CSRF, or missing seed data produce 419/429 on day one; the team suppresses the gate — the classic end state for noisy smoke tests.
• Destructive: a swept POST/DELETE mutates a shared database; recovery is manual. More likely post-v1.1.2, not less.
• Silent death: upstream breaks an interface in a patch, someone pins or skips, and the gate disappears for months without a decision.
• New: we copy the decorator design without copying the parameter-substitution rules, and every route with a required path parameter silently becomes a skipped test case.

Ramp-up. Concept curve remains negligible for anyone who knows Laravel's router. The v1.1.2 release adds maybe an hour of useful reading (resolver + decorator) and subtracts nothing. Net recommendation stands, with a sharpened rationale: adopt the pattern, reject the artifact. Allocate ~2 engineer-days to an internal route-smoke harness modeled on the decorator shape, assign a maintainer, and require the fakes/isolation guardrails above before it is permitted to gate merges. Re-evaluate upstream only if it publishes explicit platform-support constraints and a semver-respecting release history — not on the strength of one patch release.