Pest Plugin Phpstan Laravel Package

Product Decisions This Supports

• Whether test code is held to the same quality bar as production code. Static analysis on app/ but not tests/ is a common, silent split. This package is the enabler that lets you put a number on it: "our test suite is at PHPStan level 0 by default and level 8 in app/." That gap is a roadmap item, a definition-of-done change, or nothing — the plugin makes it cheap to find out which.
• CI gating strategy and spend. Adopting it means PHPStan now parses and analyses test files, which increases analysis scope and CI minutes. The decision is whether the defect class it catches (typos in expect() chains, wrong argument types passed to it()/dataset closures, unreachable assertions, broken custom expectations) is worth the added runtime and baseline churn.
• Build vs. buy for the "make PHPStan understand Pest" problem. The alternative is hand-written PHPStan stubs, a custom extension.neon, or simply excluding tests/ from analysis. This is a thin, MIT-licensed, removable integration — low lock-in, so it can be evaluated as a spike rather than a commitment.
• Framework upgrade sequencing. Pest majors and PHPStan majors both move; the plugin sits on the seam between them. Whether it is maintained in lockstep determines if "upgrade PHPStan to 2.x" or "upgrade Pest to v3" is a this-quarter or next-quarter item. That dependency adjacency is itself a roadmap input.
• Use cases it unlocks directly: analysis of dataset-driven tests (with([...])), custom expectations and Expectation extensions, beforeEach/use() trait wiring, and IDE/static feedback for engineers writing tests — meaningfully reduces the "tests are a second-class citizen" tax during onboarding and code review.
• Documentation and template decisions. If adopted, it belongs in the default phpstan.neon scaffold of your service template/repo starter, which turns a per-team debate into a one-time platform decision.

When to Consider This Package

Adopt when:

• The team is already committed to both Pest and PHPStan and has appetite to raise the PHPStan level in tests/, not just app/.
• Your test suite is large and non-trivial — heavy use of datasets, custom expectations, shared beforeEach traits, or Pest's higher-order/fluent syntax that generic PHPStan stubs misread.
• You have many contributors or contractors who would benefit from static feedback on tests before review, rather than a reviewer catching a malformed assertion.
• You are willing to pin versions tightly and re-verify compatibility on every Pest/PHPStan bump.

Look elsewhere or defer when:

• You're on PHPUnit, or running Pest and PHPUnit suites in parallel — the value is Pest-specific.
• Your PHPStan level is low (0–3) and the marginal signal in tests/ is near zero relative to the noise.
• The test suite is small or mostly smoke tests — the integration and maintenance cost exceeds the defects caught.
• A first-party or built-in path exists for your Pest/PHPStan version combination (Pest's own docs and PHPStan's extension installer evolve here). Always check whether the current major versions still require this plugin before adding a dependency — the capability may have been absorbed upstream, which would make this package redundant rather than wrong.
• Maintenance signals are weak. With ~11 stars and an unspecified repository, treat it as a small utility maintained alongside the Pest core rather than a standalone project. Verify recent commits, open issues, and explicit support for your exact Pest and PHPStan majors before depending on it in CI. A single-maintainer package that lags a PHPStan major becomes a blocker, not a helper.

Practical evaluation (one sprint, timeboxed):

1. Add the plugin on a branch, point PHPStan at tests/ at the current level, record the finding count and CI delta.
2. Raise the level one step at a time; measure whether findings are real defects or stylistic noise.
3. Delete the plugin and confirm the build still passes — if removal is painful, the coupling is worse than it looks.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk quality-control addition to how we build software — it extends the same automated code checking we already run on our product code to cover our automated tests. The business case is narrow and honest: it prevents a class of silent failures where a test looks like it's protecting a feature but isn't, which is exactly the failure mode that lets defects reach customers. Cost is a few engineering hours and some additional CI time; the package is free, MIT-licensed, and can be removed in a single commit, so downside is bounded. Recommend a timeboxed trial with a measured result rather than a standing commitment.

To engineering: This teaches PHPStan about Pest's syntax so tests/ stops being an analysis blind spot. You get type checking and IDE support on expect() chains, dataset closures, and custom expectations — catching malformed assertions at CI time instead of at 3am in a flaky-suite investigation. It's a thin extension, not a framework, so treat it as configuration: pin it, verify it against our Pest and PHPStan versions, and be ready to drop it if a first-party integration covers the same ground. Success criterion is a measurable drop in test-suite defects and a clean PHPStan run at one level higher in tests/ than we have today — not "we installed a plugin."