Mockery Module Laravel Package

Product Decisions This Supports

• Test architecture standardization: If your teams use Codeception for acceptance/functional/unit suites, this module lets Mockery serve as a first-class mocking layer alongside Codeception's native PHPUnit-based test doubles, reducing one-off bootstrap code and inconsistent mocking patterns across squads.
• Build vs. buy for test tooling: Adopting this is a low-cost "buy" (MIT, tiny surface area) versus building an in-house bridge. It is infrastructure, not product surface, so it should be evaluated on maintenance cost and CI stability rather than feature velocity.
• Migration planning: Useful signal when deciding whether to consolidate on Codeception + Mockery, move toward Pest/PHPUnit-native mocks, or keep a hybrid. It supports the "keep Codeception" branch of that roadmap decision.
• Feature-level roadmaps that hinge on testability: Areas like payment integrations, third-party API orchestration, and legacy service isolation benefit from a consistent mocking convention; this package lowers the activation energy for writing those tests.
• CI/quality-gate decisions: Because the module auto-verifies and auto-cleans expectations at test teardown, it supports decisions to enforce stricter mock verification as a gate, with less custom teardown plumbing.
• Not a product differentiator: It is an enablement dependency for engineering, not something to position in customer-facing roadmap or packaging decisions.

When to Consider This Package

Consider it when:

• Your stack is already Codeception-based and you want Mockery semantics (fluent expectations, shouldReceive, spies, partial mocks) rather than PHPUnit's native mock API.
• You want module-level lifecycle management — Mockery container init, haveMock/make/makeEmpty/haveFake helpers, and automatic expectation verification/cleanup — instead of hand-rolling this in a base test case or _before/_after hooks.
• You have multiple suites (unit, functional, integration) and want uniform mocking behavior configured once in codeception.yml.
• You need containers or partial mocks of concrete classes with constructor-arg control, which the module's helper methods make ergonomic.
• Your team is small and you value convention over configuration; the module's small API is easy to document internally.

Look elsewhere when:

• You are on PHPUnit, Pest, or Laravel's built-in test tooling — Laravel's $this->mock(), container binding, and Mockery::close() integration already cover this without a Codeception dependency.
• You require actively maintained dependencies with a current release cadence. The last release (March 2022) and low dependent count mean you should verify PHP/Laravel/Codeception version compatibility yourself and be prepared to fork or pin.
• You need deep framework integration (e.g., Laravel facade swapping, HTTP fake layers, database transaction helpers) — those belong in Laravel-specific modules, not this bridge.
• Your organization has a vendor-consolidation or dependency-minimization policy, or security review flags low-adoption packages; the value here is modest and replicable with ~30 lines of bootstrap code.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed developer tooling library that makes our automated tests easier to write and more reliable when we use Codeception. It does not ship to customers, adds no runtime risk, and costs nothing to license. The trade-off is maintenance: the project has a small community and no recent release, so I recommend adopting it only where we already use Codeception, with a documented fallback to the equivalent built-in mocking approach. Expected benefit is faster test authoring and fewer flaky or under-verified tests; expected cost is a few hours of setup and periodic compatibility checks during framework upgrades.

For engineering: This module wires Mockery into Codeception's module lifecycle — it initializes the container, exposes haveMock/make/makeEmpty/haveFake helpers on the tester, and automatically runs Mockery::close() verification at test end so unmet expectations fail the suite instead of silently passing. That removes boilerplate from base test classes and standardizes mocking across suites. Caveats: last release was 2022, adopters are few, so pin the version, confirm compatibility with your Codeception/PHP versions in CI, and keep a thin abstraction so we can swap to PHPUnit-native mocks or Laravel's container mocks without rewriting tests. Recommended decision: adopt as a dev-only dependency in Codeception-based services; do not introduce it into Laravel apps that already have first-class mocking support.