- How do I install laravel-test-lanes in a Laravel app?
- Install it as a dev dependency with composer require --dev mozex/laravel-test-lanes, then publish the package config. Provision the lane databases your test suite will use and wire the test-lanes command into your local test script or CI job in place of your normal test invocation. Because it is dev-only, nothing is added to the deployable artifact.
- Does laravel-test-lanes work with both PHPUnit and Pest?
- Yes. It works with standard Laravel testing, so both PHPUnit and Pest suites can be split into lanes and run in parallel. You keep your existing test code and only change how the test command is invoked.
- Which databases does laravel-test-lanes support?
- It targets relational databases used in Laravel CI, specifically MySQL and Postgres. Each lane gets its own database so concurrent workers do not step on each other's schema or data.
- How does laravel-test-lanes keep concurrent test runs from colliding?
- Each concurrent test process claims a machine-unique lane, and that lane maps to its own dedicated database. Parallel PHPUnit or Pest workers can then run at the same time without sharing tables or truncating each other's data. The result is predictable lane workloads instead of ad hoc database contention.
- Why does test-lanes:cleanup find no lanes when I run it from my shell?
- When you run test-lanes:cleanup from a shell, it reads DB_DATABASE from your .env file, so it will not find any lanes unless that value points at the test database, for example DB_DATABASE=app_testing. Set it explicitly in the command or environment. This is a usability trap rather than a package bug, so document it in your internal runbook.
- Is it safe to run test-lanes:cleanup --connection in CI?
- No, it should be banned in CI. The 1.2.1 release notes warn that test-lanes:cleanup --connection will drop lane databases on non-default connections even while tests are running on them, because lane locking is scoped to the default connection's database. If your suite uses more than one database connection, encode that ban as a CI guardrail rather than relying on a docs note.
- Does laravel-test-lanes add production dependencies or runtime risk?
- No. It is a dev dependency with no runtime coupling, no production schema changes, and no Composer footprint in the deployed application. The worst-case failure mode is slow or flaky CI, not a production incident.
- What changed with max_connections sizing in 1.2.1?
- In 1.2.1, max_connections sizing now accounts for every connection a worker opens rather than assuming two per worker. That is a correctness improvement, but it may expose database servers that were tuned to the old assumption. Check your database server's max_connections ceiling against your target lane count before rolling it out.
- Can I use Pest Tia or test-impact analysis with parallel lanes?
- Be careful. The 1.2.1 release clarifies that lanes leave shared state between concurrent runs, notably a per-checkout test-impact cache such as Pest's Tia. Test-impact analysis or cache-based test selection can therefore be incorrect under concurrent lane execution unless the cache is partitioned or disabled. This is the highest-impact technical note in the release.
- How do I migrate from php artisan test --parallel to laravel-test-lanes?
- Add the package as a dev dependency, publish its config, create the lane databases, and replace your php artisan test --parallel invocation with the test-lanes workflow. Then set max_connections on the database server consistent with the new per-worker sizing rule. There is no data migration and no application code change. For greenfield projects, add it as part of the initial CI test harness rather than retrofitting later.