Testing concurrent code question 165 of 180 mid
What makes a concurrency test flaky, and how do you deal with flakiness?
- Flaky tests should be annotated
@Disabled - Correct: Timing assumptions and shared state; fix the assumption instead of retrying the test
- Flakiness is inherent and unavoidable
- Running tests in parallel
The usual causes are all fixable: sleeps standing in for conditions, assertions on how long something took, shared static state or singletons leaking across tests, ports and temp files that collide, and pools not shut down so threads from one test run during another.
The cultural part is the real answer. An intermittent failure in a concurrency test is evidence of a race somewhere, in the test or in the code, and adding a retry annotation discards that evidence. Quarantine it if it blocks the build, but keep it running and keep the failure output, including a thread dump.
Useful hygiene: make each test create and shut down its own executor, give threads names that identify the test, and run the suite occasionally with more threads than cores to change the interleavings.
Quiz yourself on Testing concurrent code Suggest a correction