Tagged: Testing

Whenever two test commands ran inside one of my projects at the same time, they failed, because one run would clear the database under the other. It happened especially when I asked a Claude Code session to hand work to sub-agents: each sub-agent ran the tests for its own change, the runs failed, and it became a loop of discovering the problem and running it again. For this post I reproduced it on a fresh Laravel app whose phpunit.xml points at MySQL, with 1,201 tests, 1,200 of them using RefreshDatabase. Run alone, before any fix, the suite passes in under a minute. I started php artisan test twice at the same moment, three times. All six runs failed 1,167 to 1,200 of their 1,201 tests, and each took 3.5 to 4.4 minutes. The fix is my package mozex/laravel-test-lanes. Install it with composer require mozex/laravel-test-lanes --dev and there's nothing else to set up. With it, those runs pass. Everything here ran on Laravel 13.33, PHP 8.5, PHPUnit 12.5 with ParaTest 7.20, and MySQL 8.4 on Windows 11, with version 1.1.1 of the package (Laravel 11 to 13, PHP 8.2+, MySQL, MariaDB and PostgreSQL).

In a previous post, I listed "your job runs before the data exists" as one of five queue failures that only show up in production. I showed the afterCommit() fix and moved on. But that post didn't answer the question that kept nagging me: why do your tests always pass when this bug is sitting right in your code? And where else in your app is this same timing problem hiding, beyond direct dispatch() calls? This post digs into both.

When Pest v4 dropped, one feature got my attention right away: test sharding. My CI pipelines were painfully slow, and splitting tests across parallel GitHub Actions runners seemed like the obvious fix. I upgraded, configured the shards, pushed to CI, and waited. Every shard ran every test. Shard 1 of 4? Full suite. Shard 3 of 4? Full suite. My "optimization" made things four times worse.