Wp Mock Laravel Package

Technical Evaluation

Architecture fit — low for a Laravel codebase. 10up/wp_mock is a PHPUnit-oriented mocking framework for WordPress's procedural surface: global functions (add_action, apply_filters, get_option, wp_remote_get) and the hook system. Laravel applications do not have that surface; they have a container, facades, and first-party test doubles (Http::fake, Event::fake, Mockery integration). Adopting wp_mock in a Laravel repo inverts the testing model — it exists to simulate a global-function runtime that Laravel deliberately avoids. The only legitimate fit is a hybrid estate: a Laravel application that also ships or consumes a WordPress plugin/theme, or a monorepo where a legacy WP plugin is being progressively extracted.

Integration feasibility — feasible but narrow. Technically it installs via Composer as a dev dependency, requires a PHPUnit bootstrap that loads WP stubs before the test suite, and depends on Mockery plus a runtime function-redefinition mechanism. That mechanism is the friction point: it must patch global functions before they are bound, which constrains bootstrap ordering, interacts poorly with opcache/preloading, and can conflict with Laravel's own tests/bootstrap.php and CreatesApplication flow. It is achievable in a single test suite; keeping two bootstraps (Laravel + WP) in one process is where teams burn time.

Technical risk — elevated and concentrated in four areas.

• License: recorded as NOASSERTION. Even if the underlying license is permissive, an unattributed license is a legal-review gate before it enters a commercial build. Budget for counsel time.
• Provenance: repository metadata is unknown, which weakens supply-chain confidence; we cannot verify tag signing, release provenance, or CI status from the record alone.
• Version drift: mocks are frozen snapshots of WordPress behavior. When WP core changes a function's return shape or adds a hook, mocks keep passing. This produces false-green suites — the most expensive failure mode in a testing tool.
• Ecosystem churn: PHPUnit major-version transitions and PHP 8.x runtime changes have historically broken function-redefinition approaches; maintenance depends on a single-vendor side project.

Key questions for the maintainers / sponsors.

1. Do we actually own WordPress code, or is this being evaluated because it is a popular PHP package? If the latter, stop here.
2. Is the NOASSERTION license resolvable via a specific SPDX identifier and an OSI-approved text in the repo?
3. Which PHP and PHPUnit versions are in the supported matrix for the pinned release?
4. Does function redefinition work under our production-parity PHP config (opcache, JIT, preloading)?
5. Who internally owns the fork if upstream stalls?

Verdict. Composite score of ~22.7 with a 7.2 opportunity signal reads correctly: real value inside the WordPress niche, poor fit for a Laravel-primary stack. Recommend conditional rejection — approve only if a named WordPress component exists in scope; otherwise standardize on Laravel-native doubles.

Integration Approach

Stack fit. Treat wp_mock as a boundary tool, not a framework tool. It belongs in the test suite of a WordPress plugin/theme package, or in a legacy-migration package inside the monorepo — never in tests/ of the Laravel application itself. Keep it isolated to a Composer path/workspace package so its bootstrap and Mockery constraints cannot leak into the app's test configuration.

Migration path. The defensible use case is characterization before extraction:

1. Wrap every WordPress call site behind a thin adapter interface (OptionsRepository, HookDispatcher, HttpClient) in the legacy code.
2. Use wp_mock to pin current WP behavior and lock in regression tests around those adapters.
3. Reimplement each adapter against Laravel-native services (Config, Event::dispatch, Http).
4. Delete the WP adapter and the wp_mock dependency; the characterization tests survive as contract tests.

This converts a testing dependency into a bounded, time-boxed migration instrument with a defined exit date — the key TPM control.

Compatibility. Pin an exact version in composer.json (no caret range) and record the resolved PHPUnit/Mockery/PHP matrix in the repo. Verify the pinned release against our CI PHP version before any broader rollout; the release date metadata being ahead of the current date is itself a signal to verify artifacts manually rather than trust the index.

Sequencing.

1. Week 1 — spike: one plugin package, one bootstrap, ten representative tests, run in an isolated CI job. Success criteria: parallel test execution works, no bootstrap conflicts, no opcache configuration change required.
2. Week 2 — legal/supply chain: license clarification, source provenance check, checksum pinning, internal fork decision.
3. Weeks 3–4 — pilot: apply to one legacy module actively being extracted; measure test runtime and false-positive rate against a manual WP smoke test.
4. Go/no-go: proceed only if the pilot demonstrates mocks matching observed WP behavior; otherwise retire the tool and rely on integration tests against a real WP container.

Operational Impact

Maintenance. The ongoing cost is not the dependency — it is mock fidelity. Someone must own the mapping between WordPress core behavior and our stubs, and refresh it on WP major releases. That is a recurring, low-glamour workload with no upstream guarantee. Plan for an internal fork with a designated maintainer, or accept that the suite's trustworthiness decays between WP releases.

Support. Community-supported, single-vendor origin (10up) with a credible reputation but no SLA. Escalation path is "open an issue." For a tool that gates our test signal, that is a real support gap; the mitigation is fork-and-patch authority, not vendor commitment.

Scaling. Test suites grow, and this tool's design is hostile to scale: global function redefinition plus shared hook state makes parallel execution (Paratest) and test isolation fragile, and forces deterministic ordering or process isolation. Expect suite runtime to grow superlinearly and expect intermittent cross-test contamination that is expensive to diagnose. Keep the wp_mock suite in its own CI job so it cannot slow or destabilize the main Laravel pipeline.

Failure modes to monitor.

• False green: mocks diverge from WP core; tests pass, production breaks. Mitigate with a nightly integration job against a real WordPress instance — the mock suite is a fast inner loop, never the source of truth.
• Global leakage: unmocked function calls or residual hook state bleeding between tests, producing order-dependent flakes.
• Bootstrap conflict: wp_mock initialization colliding with Laravel's test bootstrap, manifesting as intermittent class-not-found or "function already defined" errors after unrelated dependency updates.
• PHPUnit upgrade wall: a framework major upgrade blocks the package, stalling the whole repo's test modernization. Pin the framework boundary per package to contain this.
• Abandonment: upstream goes quiet; the pinned version becomes a security and compatibility liability.

Ramp-up. A mid-level PHP developer fluent in PHPUnit and Mockery needs roughly one to two days to be productive; the real learning curve is WordPress internals — hook priority semantics, filter return contracts, and the order in which core loads — which is a week-plus for someone without WP background. Do not assume Laravel testing experience transfers; the mental model is different and the failure modes are silent. Budget a short internal write-up on "when a passing test here means nothing" as part of onboarding.

Bottom line for planning. Cost is low in license terms and moderate in engineering; the dominant risk is signal quality — a test suite that is green for the wrong reasons. Approve only with (a) a named WordPress component in scope, (b) license clarification, (c) a paired real-WordPress integration job, and (d) an exit criterion tied to the extraction roadmap.