Why Races Are Hard to Catch
Concurrency bugs are timing-dependent: the race window may be nanoseconds wide. They disappear under a debugger (the observation changes the timing), pass on your development machine, and blow up in production under load. A test that passes 1000 consecutive times on one machine does not prove thread safety — it proves that particular timing pattern didn't trigger the race. The race is still there; you just didn't shake it loose.
The Jiggle Technique
Jiggle testing deliberately destabilizes the execution order to widen race windows: (1) insert random.sleep() or thread.yield() calls at thread-switch points; (2) run the test thousands of times with different random seeds; (3) run on multiple OS and hardware combinations — different schedulers produce different interleavings; (4) vary the thread count; (5) use stress-testing tools (Java's ConTest/jcstress, Go's race detector, Python threading stress harnesses). Automated jiggle + assertion loop = a concurrency regression test that raises the probability of exposing latent races.
Code Challenge
Add a jiggle harness to expose the race, then fix it with a lock.
Key takeaway
Jiggle testing widens race windows by randomizing thread scheduling. Combine it with many repeated runs and multi-platform execution to catch concurrency bugs that deterministic tests miss.