Functional Test Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the functional-test harness. The core decision this package informs is whether your team hand-rolls REST endpoint test scaffolding (kernel bootstrapping, DB reset, fixture loading, response snapshotting) or adopts an existing base class. Buying is cheap here (MIT, --dev only), so the real cost is coupling, not license.
• Test-coverage roadmap for API surface. assertRestGetPath() / assertRestRequestReturns404() style helpers make it low-friction to add regression coverage per endpoint, which supports a decision like "freeze the public API contract with snapshot tests before a refactor" or "gate a v2 API behind full endpoint coverage."
• Snapshot-based contract testing as a release gate. Snapshot comparison means a changed response body fails CI without anyone writing field-by-field assertions. PM-relevant use case: catching unintended payload changes (added/removed fields, changed types) in a release candidate before they reach integrators.
• Integration-test depth vs. speed. Mocking services in the DI container — including private services — lets you test a controller end-to-end while stubbing a third-party client or payment gateway. That supports the decision "do we invest in real sandbox environments, or can we cover this path in CI?" It shifts cost from environment provisioning to test code.
• Deprioritizing test-infrastructure work. If adopted, it removes a recurring "we should build a better test base class" backlog item, freeing engineering capacity for product work.
• Not a product-surface decision. This is developer tooling with no direct user impact; it should be evaluated under engineering-enablement budget, not feature roadmap, and should never be a launch blocker.

When to Consider This Package

Adopt (or rather, pilot) when all of these hold:

• The application is Symfony, not Laravel. Despite the "Laravel/PHP package" framing, this is a Symfony bundle that registers via config/bundles.php and bootstraps against a Symfony Kernel. It will not work in a Laravel app without a Symfony kernel present — treat framework mismatch as disqualifying.
• Your team writes functional tests against REST/JSON endpoints and wants snapshot assertions rather than hand-written field assertions.
• You need to mock services inside the container, including private ones — a genuinely awkward problem in vanilla Symfony testing, and the strongest differentiator here.
• Your test suite already uses PHPUnit and you are comfortable with a bootstrap-file convention (require .../src/Test/bootstrap.php exposing $kernel).
• You accept the risk profile: 5 GitHub stars, 0 dependents, a single maintainer, and a bundle that is dev/test-only — i.e., contained blast radius. A breakage blocks CI, not production.

Look elsewhere when:

• The stack is Laravel. Use Laravel's built-in $this->getJson() / assertJsonStructure() helpers, Http::fake(), and RefreshDatabase. Nothing here transfers.
• You only want snapshot assertions. spatie/phpunit-snapshot-assertions is framework-agnostic, orders of magnitude more adopted, and better maintained. Pair it with Symfony's own WebTestCase and you replicate most of this bundle's value with far less bus-factor risk.
• You need fixtures at scale. Prefer doctrine/doctrine-fixtures-bundle or zenstruck/foundry for object factories; this bundle's fixture loading is thin by comparison.
• Your organisation requires active maintenance, security review, or a support contract. A 5-star, 0-dependent bundle will not pass a vendor-risk review; expect to vendor-fork it and own it internally.
• You need HTTP-level (black-box) testing against a real server rather than in-process kernel tests.
• Zero new dependencies is a hard constraint. You can approximate this with a small in-house base class in a few hundred lines.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, MIT-licensed developer tool that makes it cheaper to write automated tests for our REST APIs — specifically, it catches unintended changes to API responses before they ship. The cost is effectively zero in licence terms and it is installed only in test environments, so it cannot affect production. The caveat is that it is a niche, single-maintainer Symfony component with almost no community adoption, so we should treat it as a pilot: adopt it behind our existing test suite, keep it isolated, and be ready to fork or replace it. It is an engineering-efficiency line item, not a product bet.

For engineering (one paragraph): Symfony bundle providing RestControllerWebTestCase as a PHPUnit base class. Value props: (1) boilerplate-free kernel bootstrap via a requires-able Test/bootstrap.php, (2) DB setup + fixture loading hooks, (3) DI service mocking including private services — the differentiating capability, (4) snapshot-based response assertions so assertRestGetPath('/api/user/1') asserts the whole payload in one line. Requirements: PHPUnit, Symfony kernel, --dev install, bundle enabled in dev/test. Risks: PHPUnit/Symfony version drift, undocumented snapshot-update workflow, one maintainer. Mitigation: wrap our own thin base class over it so our tests depend on our API, not theirs; that makes a swap to WebTestCase + spatie/phpunit-snapshot-assertions a contained refactor. Success metric: time-to-add a regression test per endpoint, and count of API contract regressions caught pre-release.