Testbench Laravel Package

Product Decisions This Supports

• Engineering productivity / developer-experience investment. TestBench is a dev-only dependency that removes repetitive test bootstrap boilerplate from Laravel package work. Adopting or rejecting it is a "how do we spend engineering time" decision, not a product feature decision — the payoff shows up as faster package delivery and fewer flaky/duplicated test harnesses.
• Roadmap: framework and language upgrade cadence. The package's compatibility matrix (Laravel 8–13, PHP 7.4–8.5, PHPUnit 9–12) doubles as a scheduling input. Each TestBench major/minor release effectively signals "the Laravel N upgrade path is testable now," which lets you plan platform upgrades against a known-good testing baseline rather than discovering breakage mid-sprint.
• Build vs buy (strongly buy). Writing an in-house AbstractTestCase with app bootstrapping, config fixtures, Mockery lifecycle, and service-provider assertions is 1–3 days of work per package plus permanent maintenance. The package is MIT, free, and already composes orchestral/testbench, PHPUnit, and Mockery — there is no credible ROI case for building this in-house.
• Standardization of test infrastructure across a package portfolio. If you maintain more than one internal or published Laravel package, a shared base test case is the cheapest way to get consistent assertion behavior, mock teardown, and provider test patterns across repos. This is a platform-consistency decision more than a library decision.
• Use cases it directly enables: first-party Laravel package/SDK development, internal shared libraries (auth, billing, audit, feature-flag clients) consumed by multiple apps, and code that is heavily service-provider and container-binding oriented, where you need to assert bindings, singleton resolution, and provider registration.
• Supply-chain and support posture. Single-maintainer project with a Tidelift commercial support path. That feeds a real decision: whether to treat it as an informally trusted transitive dev dependency or to attach it to a paid support agreement alongside other critical OSS.
• Tech-debt and risk-register entries. Because the package tracks PHPUnit/Laravel majors closely and drops old versions in majors (v6.0 dropped Laravel 5.x–7 and PHPUnit 6–8), it is a recurring, low-effort but non-zero upgrade item — worth naming explicitly in planning rather than absorbing silently.

When to Consider This Package

Adopt when:

• You are building or maintaining a Laravel package/librar, not an application. This is the package's entire reason for existing.
• You maintain multiple Laravel packages and want a single, consistent base test case rather than per-repo bespoke harnesses.
• You are on a currently supported combination: Laravel 8–13, PHP 7.4–8.5, PHPUnit 9–12 (pin ^6.3 for the newest matrix).
• Your tests need to exercise service providers, container bindings, and configuration rather than just pure units.
• You want Mockery-based mocks/spies wired in by default without each team assembling the glue.
• You value zero configuration — no service providers to register, no config file to publish, extend a base class and go.

Look elsewhere or defer when:

• You are building an application. Laravel already scaffolds tests/TestCase.php; adopting a package-oriented harness here is unnecessary indirection.
• You need browser/E2E testing (Dusk, Playwright) — out of scope entirely.
• You are on legacy Laravel 5.x–6.x. Older TestBench lines exist, but you would be adopting a version pinned to an unsupported framework; upgrade instead.
• You are Pest-first. TestBench is PHPUnit-centric; extending it from Pest is possible but you lose some of the ergonomic benefit and should verify the pattern before standardizing.
• You only need one package's worth of harness. orchestral/testbench alone may cover it, and adding a second layer above it is a maintenance tax for a single repo.
• You require multi-maintainer or vendor-backed dependencies as policy. This is a single-maintainer project (with Tidelift as the commercial backstop) — if your OSS policy forbids that without a support contract, either buy the contract or don't adopt.
• Documentation inconsistency is a blocker for your team. The README simultaneously states PHPUnit 12 is unsupported and recommends sticking with PHPUnit 12; the changelog says v6.3 supports it. Resolve this ambiguity with the maintainer or by inspecting composer.json constraints before pinning in a large portfolio.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed, development-only utility — it ships nowhere near production, so the blast radius of adoption is essentially zero. It exists to make our Laravel package work faster to test and cheaper to upgrade: when Laravel or PHP ships a major version, this project ships a matching release, which turns a potentially multi-week, discovery-driven upgrade into a scheduled, predictable task. Cost is $0; the only ongoing cost is an hour or two of maintenance per framework upgrade, plus an optional Tidelift subscription if we want paid support and security-response commitments for a single-maintainer dependency. Recommendation: adopt, treat it as standard test infrastructure, and record it in the risk register with an owner.

To engineering: It's a thin, opinionated base test case over Orchestral Testbench, PHPUnit, and Mockery — abstract test cases for package and application contexts, Mockery integration for mocks and spies, helpers for service-provider and container-binding assertions, and no configuration or service providers to register. You extend a class and write tests. Version coupling is strict by design (each release targets a specific Laravel/PHPUnit window), so the practical rule is: upgrade TestBench in lockstep with Laravel minors, and never let the two drift. Before standardizing across the portfolio, verify the PHPUnit 12 support claim — the README and changelog currently disagree — and confirm Pest compatibility if any team is Pest-based. Expect a composer update-level change per Laravel major, not a rewrite; v6.0's breaking changes were return types and static signatures on the abstract cases, which is the worst case we should plan for.