Tagged: Testing

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.