- What is fp/fumocker and how does it work?
- fp/fumocker is a lightweight PHP mocking library that creates test doubles from plain closures instead of a heavy mocking framework. It generates mock classes at runtime so you can stub return values and verify method calls with argument matching and call counts. It is designed to work alongside PHPUnit without global state, though the package itself has no Laravel-specific features.
- Does fp/fumocker have Laravel integration?
- No. fp/fumocker has no Laravel integration surface: no service provider, facade, package auto-discovery, config file, or Artisan command. You could add it as a require-dev dependency and call it from a base TestCase, but that adoption cost falls entirely on your test scaffolding. For most Laravel testing needs, Laravel's built-in fakes are the first-party alternative.
- Can I install fp/fumocker on Laravel 10 or Laravel 11?
- Likely not without forking. fp/fumocker predates PHP 7 and its composer.json targets PHP 5.x, while Laravel 10 and 11 require PHP 8.1 or 8.2. Composer will normally refuse to resolve the package on a modern Laravel image. Verify in a throwaway branch before committing to any design work.
- Is fp/fumocker compatible with PHPUnit 10 and PHPUnit 11?
- Compatibility is not established from the package information and should be treated as unverified. The package predates PHP 7, while PHPUnit 10 and 11 are used by modern Laravel releases. Because the platform constraint may already block installation, you would need to fork and test it explicitly against your PHPUnit version.
- What are alternatives to fp/fumocker for Laravel tests?
- Laravel ships first-party fakes that cover most of the same ground: Carbon::setTestNow for time, Http::fake for outbound HTTP, Storage::fake and File::fake for filesystem I/O, and Bus, Event, and Queue fakes for async boundaries. Recent Laravel versions also provide Str::createRandomStringsUsing and random fakes for randomness. For classic test doubles, PHPUnit mocks or Mockery are common, and php-mock/php-mock-phpunit is a control option for function mocking.
- Does fp/fumocker require the uopz or runkit PHP extension?
- The package overview does not mention uopz or runkit; it describes runtime mock class generation and a closure-based API rather than extension-based interception. Its function-mocking behavior generally relies on namespace scoping and how files are loaded, not on a PHP extension. Check your target version and CI images before assuming extension requirements either way.
- Is fp/fumocker safe with Laravel parallel testing?
- It is a poor fit for parallel test execution. Mocks in this class of tool are process-global and can leak silently across tests if unregister is missed, which conflicts with php artisan test --parallel. Double registration can also trigger redeclare errors. Prefer isolated test processes or avoid global function mocking in parallel suites.
- How do I install and configure fp/fumocker in a Laravel app?
- Install it as a development dependency with composer require --dev fp/fumocker only if Composer can resolve it on your PHP version. There is no Laravel configuration step because the package provides no service provider, facade, config file, or auto-discovery. You would register mocks in your tests, define closure-based expectations, and ensure mocks are unregistered after each test. The PHP 5.x platform constraint will likely block installation on a modern Laravel stack.
- What are the risks of using fp/fumocker in a Laravel codebase?
- The main risk is silent no-op mocking: the mechanism only intercepts unqualified function calls in files loaded through its scope, so fully qualified calls or already-autoloaded files can leave you with green tests that assert nothing. Other hazards include global state leaking across tests, redeclare errors from double registration, and incompatibility with parallel test runs. There is also maintenance risk because the package predates PHP 7 and has very low adoption.
- Should I adopt fp/fumocker for a new Laravel project?
- No, not for a standard modern Laravel application. The PHP 5.x platform constraint conflicts with Laravel's PHP 8 requirements, the package has no Laravel integration, and Laravel's own fakes already solve most of the addressed problems. The only defensible use is a time-boxed spike in a genuinely legacy PHP 5.x or 7.x codebase outside the main Laravel app. Otherwise, refactor toward injected clocks, HTTP clients, and storage abstractions instead.