Http Factory Tests Laravel Package

Product Decisions This Supports

• Build vs. buy (test conformance): The alternative to this package is hand-writing conformance tests for all six PSR-17 factory interfaces — request, response, server request, stream, uploaded file, URI. That's several engineer-days of low-leverage work; adoption is a dev dependency and a phpunit.xml block. Clear "buy" if we ship any PSR-17 factories at all.
• Roadmap gate for HTTP library swaps: The clearest day-to-day use is an upgrade gate. Before swapping PSR-7/PSR-17 implementations (Nyholm, Laminas/Diactoros, Guzzle bridges) or bumping PHPUnit majors, run the suite against the candidate to prove no behavior drifted. This converts a class of production HTTP bugs into a CI failure.
• PHPUnit upgrade sequencing: 2.4.0's allowance of PHPUnit 13.x makes the package compatible with a modern toolchain, which turns the PHPUnit 12 → 13 migration from a blocker into a scheduling item. PM-relevant because it decides whether the testing-toolchain upgrade lands this quarter or waits.
• Feature / positioning: If we distribute an SDK or an internal HTTP client, passing this suite lets us credibly state PSR-17 conformance in docs and procurement questionnaires.
• Explicitly out of scope: This is not a replacement for Laravel's own HTTP test helpers, and it does not validate mutators or immutability (withHeader(), withStatus()). It tests creation only. Do not let a green suite stand in for application-level HTTP coverage.
• Risk posture: MIT, dev-only, zero production runtime footprint — it is a one-way door that is cheap to reverse. The cost is maintenance attention, not licensing.

When to Consider This Package

Adopt when:

• We maintain or wrap PSR-17 factory implementations in-house, or we consume PSR-7 messages in service-to-service calls, SDKs, or middleware.
• Our PHPUnit major lines up with the package constraint, and we're on PHP 8.4+ if we want the 13.x leg.
• We can run the suite as an isolated CI job, decoupled from Http::fake() and container-bound fixtures.
• We're publishing a package or exposing an HTTP surface where conformance is a selling point.

Look elsewhere when:

• We're on the standard Laravel HTTP stack (Symfony HTTP Foundation) with no PSR-17 dependency. Value here is near zero — use Laravel's native test helpers and move on.
• We need edge-case, mutator, or immutability coverage; that work stays with us regardless.
• We're pinned to PHPUnit 9 / PHP 8.1–8.3, where we'd have to fall back to the 0.7.x/1.x line — a thin maintenance signal at that end of the range.
• We need vendor support or a maintenance guarantee. ~11 stars, one maintainer, no commercial backing. Treat it as a thin CI gate, not a platform commitment.
• The 2.4.0 claim is unverified for our stack. "Allow PHPUnit 13.x" is a relaxed Composer constraint, not evidence the suite passes on 13.x. Gate adoption on seeing the build matrix.

How to Pitch It (Stakeholders)

Executives: This is a free, MIT-licensed test dependency with no production footprint and no procurement overhead. It buys back roughly several engineer-days per factory implementation and, more importantly, makes HTTP library and PHPUnit upgrades verifiable instead of hopeful — the failures it catches are the kind that otherwise surface as production incidents. It's removable in one commit, so the downside is bounded. The real risk is maintenance signal, not money or lock-in: we hedge by using it as a narrow CI gate and owning our own edge-case coverage.

Engineering: Take it as a dev dependency, write one test class per factory implementation so failures stay attributable, and run it in a dedicated CI job rather than inside the application suite. Pin PHPUnit deliberately; if both this package and PHPUnit move, do them one at a time so fallout is attributable, and confirm the expected test count actually ran — version mismatches show up as silent skips and false greens. Treat assertions as frozen at the spec level until proven otherwise and layer our own tests for mutators and custom header/URI behavior. Budget about half a day to wire it in, plus one to two days of PHPUnit-13 migration friction (attributes over annotations, removed mocking APIs) if we upgrade in the same cycle.