Double Laravel Package

Product Decisions This Supports

• Test-strategy standardization: Decides whether the team adopts a single, expressive test-double API (this package) instead of a mix of PHPUnit's built-in createMock() and Mockery. This is a platform/consistency decision more than a feature decision.
• Build vs. buy for test tooling: Testing ergonomics are pure overhead to the product. Buying (i.e., adopting an MIT-licensed dev dependency) beats building an in-house mocking helper — the only real cost is migration and team familiarity.
• Developer velocity and onboarding cost: The package's stated value is developer experience. That directly affects how quickly new engineers write meaningful tests, and how often existing tests are skipped because mocking is painful. A measurable proxy: time-to-first-PR-with-tests for new hires, and count of tests skipped/disabled.
• Test-suite maintenance budget: A DX-first API typically means shorter, more readable arrange steps. That lowers the ongoing cost of refactoring tests when production code changes — a recurring line item, not a one-off.
• Roadmap gating for test debt: If mock setup is a known friction point (e.g., legacy Mockery expectations that are brittle or hard to read), this becomes a candidate for a scoped "test infrastructure" initiative rather than being folded into feature work.
• Risk posture on dependencies: This is a dev-only dependency — it does not ship to production. That materially lowers the risk of adopting a small, single-maintainer package, and is the key fact that makes the build-vs-buy call easy.
• Use cases where it fits best: service/unit-level tests with collaborator-heavy code (controllers, actions, jobs), and teams already on modern PHP tooling who want terse, intention-revealing doubles.

When to Consider This Package

Adopt when:

• The team writes a substantial volume of unit/service tests with collaborators and currently finds mock setup verbose or hard to read.
• You are starting a new codebase or a new test suite where there is no migration cost — greenfield is where the DX payoff is highest.
• You want one convention across teams and are willing to document it; a single blessed double API reduces review friction.
• Your CI and PHP version support it, and tests are already containerized/isolated so a dev dependency swap is a contained change.
• Someone on the team can own the choice — a named maintainer internally who will handle upgrades and answer questions.

Look elsewhere when:

• You have a large Mockery or PHPUnit-mock footprint. Migration is real work with no user-facing payoff; only do it if you are already touching those tests.
• You need framework-level features (full test runner, assertion library, browser/E2E, database fixtures). This is a test-double library, not a testing framework — pair it with PHPUnit/Pest rather than treating it as a replacement.
• Procurement/security rules penalize low-adoption dependencies. 88 stars and an unknown/unspecified repository location is thin social proof; some organizations require minimum adoption or provenance checks for any dependency, dev-only or not.
• You need vendor SLAs, long-term support, or a broad plugin ecosystem. Single-maintainer, MIT, community-supported. There is no support contract.
• Your team is small and already comfortable with existing mocks — the switching cost exceeds the ergonomic gain, and consistency matters more than elegance.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small, MIT-licensed PHP library that makes writing test doubles — the fake objects used to isolate code in tests — faster and more readable. It is a development-only dependency: it never ships to production, so it carries no runtime or customer-facing risk, and it can be removed by changing test code alone. The business case is developer throughput and lower long-term test maintenance, not a product feature. The main caveat is maturity: it is a young, single-maintainer project with modest adoption, so we would adopt it deliberately — starting with new tests, keeping existing mocks in place — and cap our exposure.

For engineering leads:

• What it is: a modern test-double library for PHP, DX-first, sitting alongside PHPUnit/Pest rather than replacing them. Same job as Mockery or PHPUnit's mock builder, with a terser, more intention-revealing API.
• Cost: near zero in license terms. Real costs are (a) learning curve, (b) migration if we standardize on it, (c) upgrade/ownership burden.
• Risk: low blast radius because it is dev-only. Primary risk is maintenance continuity of a small project — mitigate by pinning a version, isolating usage to new tests, and designating an internal owner.
• Recommendation: trial it on one team or one new module for a sprint. Success criteria: reviewers prefer the resulting tests, no measurable CI slowdown, and no blocking gaps in mocking capability versus what we do today. If it clears that bar, document it as the default for new tests and leave legacy mocks alone until they are touched for other reasons.