Wp Mock Laravel Package

Product Decisions This Supports

• Build vs. buy for test infrastructure. WP_Mock is a dev-only (require-dev) dependency that lets us unit-test WordPress-facing PHP without booting WordPress, a database, or wp-env. The decision it unlocks: invest in a fast unit suite instead of bespoke harness code or slower container-based CI. Because it never ships to production, adoption is reversible — this is a low-risk pilot, not an architecture commitment.
• Where to draw the unit/integration line. It forces an explicit portfolio decision: which code is "logic we own" (pricing rules, permission mapping, payload shaping, shortcode/block render callbacks, REST controllers) versus "wiring WordPress owns" (hook registration, capability checks, DB, multisite). That boundary drives CI design, test runtime budgets, and how much of the pipeline needs a real WP instance.
• Refactor and upgrade risk. Mocking apply_filters, get_option, transients, WP_Error, and wp_remote_* surfaces exactly which WordPress APIs a feature depends on. That's the input for scoping WP core upgrade work, deprecation timing, and go/no-go on legacy plugin refactors — with coverage as the gate.
• Roadmap and quality gating. Enables coverage thresholds on WP modules, which supports concrete calls like "can we support N-2 WordPress versions," "can we safely extract business logic out of plugin globals," and "do we gate releases on unit tests or only smoke tests."
• Tooling consolidation. If we run Laravel services and WordPress products side by side, this is the bridge that keeps both on Composer + PHPUnit + Mockery in one pipeline, rather than two test philosophies. It is WordPress-specific — it does nothing for Laravel service code, where Http::fake/Mockery already cover the ground.
• Vendor and maintenance exposure. One maintainer (10up), community-standard but unsupported. The recurring cost is tracking PHPUnit/Mockery major versions, not license fees. Budget that as ongoing engineering time, not a one-time install.

When to Consider This Package

Adopt when:

• We already run PHPUnit (it's Mockery-based and slots into existing suites) and own WordPress plugins, themes, or a headless WP backend with meaningful business logic.
• The current pain is real: tests are slow or flaky because they need a live WP install or DB, PR feedback is measured in many minutes, and WP glue code has near-zero coverage.
• We need to exercise hook callbacks, shortcodes, options/transients, and error paths without standing up core.
• We want the de facto community standard rather than maintaining a homegrown function-stubbing harness.
• Legal confirms the license. Metadata reports NOASSERTION; the project is widely understood to be MIT, but this must be resolved in writing before commercial adoption — it's a one-line blocker, not a design question.
• We verify release health: the last release is dated 2026-07-03, which looks like a metadata artifact — confirm actual cadence and maintainer responsiveness, then pin a version.

Look elsewhere when:

• We need fidelity: real hooks firing, DB state, capability checks, REST round-trips, multisite behavior. Use wp-env, the WordPress core test suite (WP_UnitTestCase), or Playwright. A mock will happily confirm behavior real WordPress would never exhibit.
• The target is editor-side block behavior (JS) — that's @wordpress/scripts and Jest.
• There is no WordPress surface. For Laravel/Symfony services this package is simply out of scope.
• The team leans zero-mock or relies heavily on WP core internals; stubbing procedural functions invites brittle tests that assert implementation rather than outcomes.
• We require commercial support or SLAs. 10up maintains this as OSS; there is no vendor to escalate to.

Adoption conditions: pilot on one plugin or module, measure CI duration and defect escape rate before and after, and keep a thin integration suite so mocks never become the only source of truth.

How to Pitch It (Stakeholders)

To executives: This is a free, development-only dependency that makes our WordPress code testable in CI without spinning up WordPress instances. Expected returns are faster PR feedback, fewer regressions when WordPress ships updates, and lower CI infrastructure spend. Risk is contained: it is not shipped to production and can be removed in a day. Two things to clear — a license confirmation (metadata is ambiguous) and a small, ongoing engineering cost to keep it aligned with PHPUnit releases. Recommend a time-boxed pilot on one product with a measured before/after on CI time and escaped defects.

To engineering: WP_Mock is a Mockery-based framework that stubs WordPress's procedural API — add_action, apply_filters, get_option, transients, WP_Error, wp_remote_* — so hook callbacks, shortcodes, and extracted business logic can be tested without a full WP bootstrap. It complements rather than replaces wp-env/WP_UnitTestCase: unit tests for logic we own, integration tests for wiring WordPress owns. Three asks: pin the version, assign an owner for the PHPUnit/Mockery upgrade path, and keep at least one real-WordPress smoke suite so mocked assumptions get checked against reality.

Framing note: despite the "Laravel/PHP" label, this is a PHP Composer package specific to WordPress. It belongs in the WordPress product line's toolchain, not in Laravel service repos — worth stating explicitly so it isn't mis-scoped into the wrong backlog.