Http Factory Tests Laravel Package

Technical Evaluation

Architecture fit: This is not a Laravel package and should not be evaluated as one. It is a framework-agnostic PHPUnit conformance suite for PSR-17 HTTP factory implementations — request, response, server request, stream, uploaded file, and URI factories. Laravel's HTTP layer is built on Symfony HTTP Foundation, not PSR-7/PSR-17, so a vanilla Laravel application has zero surface area for this package. The business case only exists where the product explicitly adopts PSR-17 factories: outbound SDK clients, service-to-service integrations, microservice boundaries, or middleware that exchanges PSR-7 messages (Nyholm, Laminas/Diactoros, Guzzle's PSR-17 bridge). The TPM decision is therefore binary and gated on one question: do we own or depend on PSR-17 factory code? If no, this is a no-op and should be closed out. If yes, it is a cheap, high-leverage correctness gate.

Integration feasibility: High where relevant, near-zero effort. It is a dev-only Composer dependency plus test classes extending the provided base cases. There is no runtime footprint, no migration, no production deployment surface, and no container or framework coupling. The practical cost is roughly half a day for a PHP-fluent engineer to wire it in, plus one to two days if the team simultaneously migrates to PHPUnit 13 conventions (attributes instead of annotations, static data providers, removed mocking APIs). Version alignment is the only real integration hazard: 2.4.0 targets PHPUnit 13.x, which requires PHP 8.4+, so teams on PHP 8.1–8.3 must pin an older line of this package and gain nothing from the latest release.

Technical risk: Moderate, and mostly organizational rather than technical.

• Maintenance signal is thin but non-zero. ~11 stars, no commercial backing, single-maintainer risk. The 2.4.0 release (allowing PHPUnit 13.x) disproves the earlier "abandoned since 2020" read, but one dependency bump does not establish a cadence.
• Constraint widening is not validation. "Allow PHPUnit 13.x" proves the Composer guard was relaxed, not that the assertions pass under 13.x. Until we see the CI matrix, treat 13.x support as unverified.
• Assertion logic may lag the spec. No changelog entry mentions PSR-17 edge cases or header validation rules. The suite validates creation only — mutator behavior (withHeader(), withStatus()) is out of scope and must be covered by our own tests.
• Silent skips are the dangerous failure mode. When the package version and PHPUnit version drift, tests can be skipped or fail to be discovered, yielding a green build that proves nothing. This is the risk a TPM should explicitly own, because it looks like success.
• Opportunity cost is negligible. The package is free, MIT-licensed, and dev-only — the decision cost is engineering attention, not budget.

Key questions:

• Do we actually own or depend on PSR-17 factory implementations anywhere in the estate? If not, this evaluation terminates here.
• Does 2.4.0's CI exercise the suite against PHPUnit 13.x, or was the constraint merely widened? Request the build matrix.
• What PHP and PHPUnit versions are our candidate services on today, and when do we reach PHP 8.4?
• Is the test count stable across runs (no silent skips), and do we have a baseline assertion count to compare against?
• Are there known interactions between the conformance suite and Laravel's test helpers (Http::fake(), container-bound factories) when run in the same suite?

Integration Approach

Stack fit: Narrow and deliberate. Appropriate only for Laravel services that already hold PSR-17 factories — typically SDK clients, integration adapters, or services calling third-party APIs through PSR-18 clients. It should never be adopted as a substitute for Laravel's native HTTP test helpers or as a general "HTTP testing" tool. Positioned correctly, it is a compliance gate on a specific dependency; positioned incorrectly, it is dead weight in the test suite.

Migration path:

1. Confirm the PSR-17 factory inventory and record the owning team for each implementation.
2. Add as a dev dependency with a pinned constraint matched to the current PHPUnit major: composer require --dev http-interop/http-factory-tests:^2.4.
3. Surface version conflicts before writing tests: composer why-not phpunit/phpunit 13.x.
4. Create one test class per factory implementation, extending the provided base cases, so failures are attributable to a single library.
5. Isolate the conformance suite from Laravel's HTTP test helpers to avoid fixture and container coupling.
6. Add a dedicated CI job so the conformance suite can track the newest PHPUnit line independently of the main application test job.

Compatibility: Materially improved by 2.4.0 but conditioned on runtime. PHPUnit 13 implies PHP 8.4+, so the upgrade is only actionable for services already on 8.4; everything else pins an older line. Teams must also verify that PHPUnit 10+ breaking changes (annotations → attributes, getMock() removal, withConsecutive() removal, static data providers) do not break any overridden test methods. Where individual tests are overridden — for example custom multipart handling in testCreateUploadedFile() — those overrides must follow modern PHPUnit conventions, not older tutorials.

Sequencing: Treat this as a low-priority, opportunistic adoption, not a roadmap item. Three triggers justify pulling it in:

• New PSR-17 adoption: wire the suite in at the same time as the factory implementation, before that code ships.
• Library swap or upgrade: use it as an upgrade gate when swapping PSR-7/PSR-17 implementations or bumping the PHPUnit major — this is its highest-value day-to-day use.
• PHP 8.4 migration: bundle it with the PHPUnit 13 bump, but land it as a separate, isolated dependency PR so any fallout is attributable. Never upgrade PHPUnit and this package in the same commit as application changes.

Operational Impact

Maintenance: Low, bounded, and largely passive. The package is dev-only with no production runtime, so there is no patching cadence, no security surface, and no version-coupling to the application's dependency graph. The prior "fork-and-patch" concern over PHPUnit friction is resolved by 2.4.0. Budget a quarterly compatibility check rather than continuous upkeep: confirm the installed version still resolves against the current PHPUnit major and that the suite still executes rather than silently skipping. Expect to own patches for spec edge-case gaps; the package will not cover them.

Support: Minimal and internal. Weak community signal, sparse documentation, no vendor relationship, no SLA. Debugging will depend on in-house PHPUnit and PSR expertise. The 2.4.0 release modestly improves confidence that contributions are reviewed, but it should not be read as a support commitment. Treat the package as unmaintained-but-working source you are willing to patch, not as a dependency with an owner.

Scaling: Effectively free. Tests scale linearly with the number of factory implementations under test — typically two to four in a mid-size estate — and the suite is pure unit work with no I/O, containers, or network. The only scaling cost is CI wall-clock time if a new PHPUnit matrix leg is added; scope the conformance job to the relevant factories rather than running the full suite per implementation, and keep it in a separate job so it does not slow the main application pipeline.

Failure modes:

• Green CI that proves nothing — the dominant risk. Version drift causes silent skips; enforce an expected assertion count or fail the job if the test count drops.
• Stale assertions — no spec-level updates announced since the suite's early releases, so post-2020 PSR-17 edge cases may be unverified.
• Runtime mismatch — PHPUnit 13 on PHP < 8.4 fails at install time; projects on 8.1–8.3 get no benefit from 2.4.0.
• Toolchain coupling — conflicts with Laravel's HTTP test helpers or container bindings if the suite is not isolated.
• Bus factor — a single-maintainer project could stall again, stranding future PHPUnit and PHP upgrades for anyone depending on it.
• Scope overreach — stakeholders assuming this validates Laravel's HTTP layer or PSR-7 mutator behavior. It does neither; set that expectation explicitly up front.

Ramp-up: Low. A PHP-familiar engineer needs roughly half a day to wire the suite in and interpret failures, plus one to two days to resolve PHPUnit 13 migration issues if upgrading concurrently. No specialist knowledge beyond the PSR-17 factory contracts is required. Crucially, the effort is per-service, not per-organization — reuse a single shared test class across services to keep the cost flat.

TPM recommendation: Fund this only for services with confirmed PSR-17 factory ownership, scoped as a few days of engineering inside an existing PSR-7/PHPUnit upgrade effort. Do not create a standalone workstream. The one safeguard worth insisting on is a CI check that the suite actually ran the expected number of assertions — without it, the package's entire value proposition dissolves into a green checkmark.