Fumocker Laravel Package

Product Decisions This Supports

• Build vs. buy for test infrastructure: Informs whether to adopt a third-party utility or invest in refactoring to seams (injected clocks, HTTP/filesystem adapters). The relevant comparison is not "cost of license" (MIT, zero) but cost of ownership — this package shifts maintenance burden onto your team.
• Legacy modernization sequencing: Decides whether hard-to-test legacy paths get test coverage now (cheap, via function mocking) or refactored first (expensive, but removes the debt). This is a roadmap question about a codebase, not a customer-facing feature.
• CI reliability investment: A dependency-light way to freeze time and randomness, reducing flaky builds and false-negative pipeline failures. Relevant if the team lacks a Clock/Randomizer abstraction today.
• Tooling standardization: A candidate for the "approved dev-testing utilities" list. Adopting it means choosing namespaced function mocking over PECL extensions (runkit7/uopz) or over DI/clock patterns — that's a standards call with long-tail consequences.
• Explicitly not a product feature: This is engineering enablement. It should be evaluated against developer productivity and quality-gate metrics, not user value, conversion, or retention. Don't put it on a customer roadmap.

When to Consider This Package

Consider it when:

• You maintain legacy PHP where functions like time(), rand(), file_get_contents(), or curl_exec() are called directly and cannot be wrapped or injected without a rewrite that isn't funded.
• Your CI and hosting environments cannot install PECL extensions, ruling out the extension-based mocking route.
• You need targeted control over time, randomness, or I/O inside an otherwise simple unit test suite.
• You want a small, MIT-licensed, zero-runtime-dependency helper that can be pinned and vendored inside a contained test suite.
• The scope is a time-boxed pilot or a single legacy test area, where a lightweight shim beats a framework migration.

Look elsewhere when:

• You are writing new code — prefer dependency injection, a PSR-20 clock, or injected HTTP/filesystem abstractions over mocking built-ins.
• You are on modern PHP 8+ / PHPUnit 10+, where php-mock/php-mock-phpunit, Mockery, or Symfony's Clock are better maintained and better documented.
• Longevity and community support matter: 7 stars, 0 dependents, and a low overall score indicate negligible adoption. Assume you will own every fix, and expect the package's PHP 5.x-era Composer constraints to fight a PHP 8 project.
• You need static-analysis and IDE friendliness, active issue triage, security patching, or support in parallel test runners — process-global function mocking interacts badly with isolation, opcache/JIT, and PHPUnit lifecycle hooks.
• The exit cost is unacceptable: adopting it creates a set of tests that only pass on a legacy image, which can block a future platform upgrade.

How to Pitch It (Stakeholders)

For executives: This is a zero-cost, MIT-licensed testing utility that helps engineers get automated test coverage onto older PHP code without a rewrite. It carries no licensing cost and no production runtime risk, because it is dev-only. The catch is maturity: near-zero community adoption, no vendor support, and a pre-PHP-7 footprint mean the ongoing maintenance is ours, not the community's. Treat it as a tactical, time-boxed pilot with a decision gate — not a platform commitment. Recommendation: fund a short spike in one legacy test area, run it head-to-head against a better-supported alternative, and require a documented exit plan before any broader rollout. Do not let a 7-star test helper hold back a platform upgrade.

For engineering leads: Fumocker lets tests override unqualified PHP function calls without PECL extensions, which is genuinely useful for legacy paths that hit globals directly. The trade-offs are maturity and mechanics: mocks are process-global and can leak between tests, only unqualified calls are interceptable, and code must be loaded through the scope after registration — meaning opcache off in CLI and careful setUp/tearDown discipline. Constrain it: dev-only dependency, exact version pin, isolated test groups, a base test case that always unregisters, and a @todo extract marker on every mock so the count is tracked as debt. Pilot on one suite, measure setup friction and stability gain, and standardize only if it clearly beats php-mock/php-mock-phpunit or a straight refactor. If it can't be installed on your current PHP line, stop — don't bend the platform for a test utility.