- How do I install ParaTest in a Laravel project?
- Install it as a dev dependency with composer require --dev brianium/paratest, then run vendor/bin/paratest instead of phpunit. ParaTest is zero-configuration and works with Laravel's existing phpunit.xml and .env.testing files. Make sure the pcntl extension is enabled and your PHPUnit version satisfies ParaTest's constraint.
- Does ParaTest work with Laravel's phpunit.xml and .env.testing files?
- Yes. ParaTest is designed as a drop-in replacement for PHPUnit's sequential runner and works with Laravel's default phpunit.xml and .env.testing configuration. You run vendor/bin/paratest and it splits tests across processes without additional bootstrap files. Any environment-specific settings in .env.testing are loaded by each worker as usual.
- How do I isolate databases per process when running ParaTest with Laravel?
- Use the TEST_TOKEN environment variable that ParaTest sets uniquely for each running process, for example testdb_ plus getenv('TEST_TOKEN') for the database name. Laravel can then connect each worker to its own database, which avoids collisions in Eloquent and query builder tests. ParaTest also provides UNIQUE_TEST_TOKEN when you need a value unique per run and per process.
- What PHPUnit version does ParaTest require for Laravel projects?
- The latest ParaTest v7.26.0 requires phpunit/phpunit ^13.4 and enforces that constraint at install time. ParaTest only actively supports the latest PHPUnit version because it relies on PHPUnit internal classes. If your Laravel project is pinned to PHPUnit 13.0 through 13.3, pin ParaTest to ^7.22 until you can upgrade.
- Can I use ParaTest as a drop-in replacement for phpunit in Laravel?
- Yes, for well-written tests. After installation you run vendor/bin/paratest instead of phpunit, and it parallelizes by TestCase by default. You can also use vendor/bin/paratest --functional to parallelize by Test. Test files generally need no changes unless they rely on shared static state.
- Why do my Laravel tests fail with ParaTest due to static state?
- ParaTest runs tests in separate processes, so static variables, static methods, and shared in-memory caches are not shared between workers in the way a sequential PHPUnit run might expect. This is a high-severity risk for test suites that depend on global or static initialization. Refactor those dependencies to instance-based or file-based coordination, or use the lock pattern described in ParaTest's README.
- Does ParaTest support code coverage reports for Laravel test suites?
- Yes. ParaTest runs tests in N parallel processes and combines all code coverage output into one report. A typical CI command is vendor/bin/paratest --processes=4 --coverage-clover=coverage.clover. PCov or Xdebug may need to be explicitly enabled, for example with --passthru-php="-d pcov.enabled=1".
- Is the pcntl extension required to run ParaTest in CI?
- Yes, ParaTest uses PHP's pcntl extension to distribute test execution across processes. Most Linux CI runners such as GitHub Actions have it available, but Windows and some macOS environments may need Docker or additional setup. Confirm pcntl is enabled in every CI environment before adopting parallel test runs.
- How do I handle Laravel service container singletons when using ParaTest?
- Singleton bindings registered with App::singleton() can persist or behave differently across parallel processes, which is a medium-severity concern. Prefer bindWhen or per-test bindings so each test gets the dependencies it expects. Review custom service provider registrations for state that should not be shared between workers.
- What should I check before upgrading to ParaTest v7.26.0 in a Laravel project?
- v7.26.0 is a dependency-pin release that adds support for and requires phpunit/phpunit ^13.4, with no new runtime features or API changes. Check composer.lock for your pinned PHPUnit version and plan a full test-suite validation run, since PHPUnit minor releases can change assertion or mocking behaviour. If the upgrade is not scheduled, pin ParaTest to ^7.22 to avoid an unplanned PHPUnit bump in CI.