Pest Plugin Global Assertions Laravel Package

Product Decisions This Supports

• Build vs. buy for internal test tooling. The real decision is not "adopt this plugin" — it's "do we maintain a shared assertion library at all, and if so, as a dependency, a vendored fork, or a trait/helper file we own?" The plugin's only differentiator is that an assertion declared once in tests/Pest.php becomes globally callable without uses(SomeTrait::class) boilerplate in every file of a monorepo.
• Whether to standardize a domain assertion vocabulary. Making business rules readable in tests (toBeRefundable, toBeWithinDays(14), toAllBePublished) is a product decision about how legible and reviewable our specification of business rules is to non-authors — QA, analysts, and new engineers — not a code-style preference.
• Roadmap input for a platform/QA function. Is test-authoring experience worth a sprint? The pilot is cheap (MIT, require-dev, reversible in an afternoon), so it should be framed as a measured experiment with a defined success bar and exit path, not a platform commitment.
• Upgrade gating. Pest-major compatibility is a concrete input to any Pest v2→v3 (or PHPUnit-major) migration plan. A low-adoption dev plugin that fails on upgrade converts an annoyance into a roadmap blocker, so it belongs on the platform backlog as a tracked risk the day it becomes load-bearing.
• Explicit non-decisions. It has zero runtime footprint and never ships to customers. It must never enter production-architecture, performance, or customer-facing feature discussions — stating that boundary up front is itself useful when socializing the work.

When to Consider This Package

Consider it only when:

• The team is already on Pest (not plain PHPUnit) and has three or more custom assertions reused across three or more test files or packages. If you can't name three, you don't need it.
• The duplication cost is measurable today: copy-pasted helper closures, or a trait that must be imported into dozens of files.
• You want a greppable, discoverable registry of domain rules owned by a platform/QA function, made global without per-file wiring.
• You can treat it as an experiment: version pinned in require-dev, piloted in one non-critical module, with the exit path documented before the pilot begins.
• The assertions are cross-cutting policy ("every Money is formatted de_DE"), not one-file conveniences.

Look elsewhere when:

• expect()->extend() plus a shared file loaded from tests/Pest.php already covers the need. This is the most common reason to say no — core expectation extensions solve most "custom assertion" requirements with no extra dependency, and the pitch must be explicitly better than this baseline.
• The suite is PHPUnit-only — a base TestCase or trait is idiomatic, and there's no Pest migration to justify the fit.
• Dependency governance is strict. With 7 stars, 0 dependents, and no visible field adoption, abandonment risk dominates the value and there's no ecosystem gravity to justify an exception.
• You have Pest/PHPUnit/PHP version constraints the plugin doesn't explicitly support, or parallel-testing and Laravel test-lifecycle behavior (RefreshDatabase, pest --parallel) are unverified and you can't absorb a compatibility spike.
• The need is a handful of assertions in a single project.

How to Pitch It (Stakeholders)

To executives: This is a development-only, MIT-licensed micro-plugin that lets us define a custom test assertion once and reuse it everywhere. It carries no production risk — nothing ships to customers, there's no runtime footprint, and it can be removed in an afternoon. The upside is less duplicated test code and tests that read in business language; the downside is that it's a very small, very young project with single-digit stars and zero downstream dependents. Frame it as a low-stakes, reversible experiment sized accordingly, with an explicit success bar: reduced duplicated assertion code, clearer tests, and surviving at least one Pest upgrade without blocking the team.

To engineering: Adopt only if we have a genuine library of shared domain assertions and want them globally callable without uses() boilerplate. Be honest about the overlap — expect()->extend() already solves most of this, so the justification must be "we have many assertions and want them callable without chaining or trait imports," not "custom assertions are nice." Before adoption: read the registration class in vendor/ as the de facto documentation (the README doesn't fully describe registration, $this binding, or the return contract), confirm Pest-major and PHPUnit compatibility, pin the version, and verify behavior under parallel testing. Then pilot in one non-critical module for a sprint, compare against the expect()->extend() + bootstrap alternative on the same measurements (duplicated helpers eliminated, files touched, reviewer comments attributable to test noise), and decide to standardize, vendor the MIT code, or fold the assertions back into a local trait. Assign an internal owner to track Pest upgrades so an abandoned dev dependency never becomes the thing that blocks a framework migration.