Pest Plugin Testbench Laravel Package

Product Decisions This Supports

• Whether to unify the test toolchain across the whole Laravel estate. Most orgs drift into a split state: applications on Pest, internal packages on PHPUnit, because Orchestra Testbench — the standard harness for testing Laravel packages — has historically been PHPUnit-shaped. This plugin is the adapter that closes that gap. It answers one narrow question: "can we run one runner everywhere, including packages?" Until the package side is covered, the answer is no.
• Build vs. buy on test-harness glue — and it's clearly buy. The alternative is owning your own Pest ↔ Testbench bootstrap: uses() bindings, a base TestCase, fixture wiring. That glue breaks quietly on every Pest or Testbench major. The release history is the product here — Pest v3 (v3.0.0), Pest v4 (v4.0.0), Pest v5 (v5.0.0), Testbench v10 (v3.2.0), PHP 8.4 (v3.1.0/v3.1.1), Laravel v13 (v4.1.0), WithFixtures support (v2.2.0/v3.3.0). You are buying someone else's upgrade chores, and the someone is the same organization that ships Testbench.
• Investment in internal packages and shared libraries. Any roadmap that says "extract shared logic into first-class internal packages" implicitly commits to giving those packages first-class test infrastructure. Package authors are a small, high-leverage population; tooling friction there suppresses contribution and slows the libraries roadmap. This is the cheapest way to remove one category of that friction.
• Upgrade-calendar planning. Adopting this makes every Pest major a coordinated three-way bump (Pest + Pest Plugin Laravel + this plugin), and every Laravel/Testbench major a reviewable line item. That's a real cost, but naming it explicitly is better than discovering it mid-upgrade. It converts an invisible dependency into a scheduled one.
• Dependency-risk posture. Zero dependents and a low star count are usually a red flag in a dependency-approval review. Here the mitigating fact is organizational stewardship — same maintainers as Testbench — which is the more predictive signal. This package is a good forcing function for deciding whether your approvals process evaluates who maintains a dependency or just its download counts.
• Developer-experience and hiring narrative. Pest's expressive syntax is a recruiting and onboarding asset. Being able to offer it consistently, rather than "apps get Pest, packages get PHPUnit," is a small but genuine DX win.

When to Consider This Package

Adopt when all of these hold:

• You maintain one or more Laravel packages (not applications) tested against a bootstrapped Laravel skeleton via Orchestra Testbench.
• Pest is already the runner, or is an approved direction with an owner.
• You want a single runner across apps and packages — the consolidation is the actual business case. If you're not consolidating, you're just adding a dependency.
• You are willing to own the version matrix explicitly (Pest ↔ Pest Plugin Laravel ↔ Testbench ↔ this plugin), ideally pinned in a shared CI template.
• You can absorb a phased migration: PHPUnit and Pest coexist in one repo, so no repository has to go dark. Budget for converting annotation-style tests (@test, deep setUp() inheritance, data providers) rather than assuming a flag day.
• You will capture a green/red baseline before adoption. This is non-negotiable, because the dangerous failure isn't a red build — it's a green build for the wrong reason, where a Testbench trait didn't actually apply under Pest and tests pass against leaked or uninitialized state.

Look elsewhere when any of these hold:

• You only ship applications, not packages. This is a category error; pestphp/pest-plugin-laravel is the right answer.
• PHPUnit is mandated by policy or your team has no Pest appetite. Stop the evaluation — the value is zero and the surface area is pure overhead.
• The codebase is pure unit tests with no container, no service providers, no HTTP/database assertions. There's nothing for Testbench to bootstrap.
• Procurement or dependency policy requires vendor documentation or an SLA. There is no vendor, no SLA, and the README's "Official Documentation" section is literally commented out. Expect the team to learn from Pest's and Testbench's docs plus source reading; price that ramp-up in rather than discovering it in week two.
• You need this package to solve CI reporting, parallelization, or browser testing. It won't. Those are out of scope, and a plan that assumes otherwise will slip.
• You can't take a Pest major upgrade when it lands. The version lines (v2/v3/v4/v5) are not interchangeable, and a repo that falls off the supported matrix quietly becomes a maintenance problem.

How to Pitch It (Stakeholders)

For executives — one paragraph. We maintain Laravel packages, and our testing toolchain is split: apps run Pest, packages run PHPUnit, because the package-testing harness we depend on has historically been PHPUnit-shaped. This is a small open-source adapter that closes that gap. It's one dev dependency, it ships nothing to production, and it's maintained by the same team that maintains the harness itself — which is why we'd buy this rather than build and maintain our own version. The ask is not a budget line. The ask is permission to run a two-week pilot on one internal package, with a measured baseline and a rollback path agreed before we start.

For engineering leads — the three facts that matter.

1. No flag day. PHPUnit and Pest run side by side in the same repo. We convert incrementally, package by package, and nothing goes dark for a sprint.
2. Cheap to reverse. The surface area is a single require-dev line and a uses() binding in pest.php. Reverting a pilot is a one-commit operation.
3. The real work isn't installation, it's inventory. Most of the schedule is auditing which existing tests are annotation-style and need rewriting versus which run untouched. Sequence it: baseline → install alongside → pilot one package → run both in parallel for a sprint → cut over once Pest is the authoritative green/red source in CI.

The honest risk statement — say this out loud, don't bury it.

• Bus factor is the top risk, and it's mitigated but not eliminated. Zero dependents and a low star count read as abandonment in isolation. The counter-evidence is the maintainer's track record of tracking upstream majors promptly. Keep the fork path documented anyway — the code is small enough that a fork is a managed fallback, not a catastrophe.
• The failure mode we're actually worried about is a green build for the wrong reason. If a Testbench trait doesn't fully apply under Pest — database isolation, fixtures — tests can pass while asserting against leaked state. That turns a tooling change into a quality-signal problem, which is materially worse than a failed migration. Mitigation: a pre-adoption baseline plus an explicit assertion that isolation actually engaged.
• Documentation is thin. One engineer should be designated internal reference and write a short internal README covering the binding pattern and the version matrix. That's the real ramp cost.

What not to promise. Don't sell this as velocity. The value is reduced toolchain divergence and one fewer bespoke integration for us to own. Don't claim it fixes CI reporting, test parallelization, or browser testing — it doesn't, and if Pest's output format breaks an existing reporter we should find that during the pilot, not at cutover.

Decision requested: approve a two-week pilot on one moderately-covered internal package, with success criteria and a rollback path defined up front, and a named owner for the Pest ↔ Pest Plugin Laravel ↔ Testbench version matrix.