Tests bring their own world
A suite that starts and tears down its own dependencies produces the same verdict on any machine, which is the precondition for treating red as information rather than as weather.
Do this firstOne command builds and tests the project from a clean checkout · Pin every dependency to an exact version
The suite starts what it needs, uses it, and destroys it. No shared database, no “make sure the service is running first”, no ordering between test files.
This is the expensive one on this sector and it is worth being honest about that: containerising a test environment is days of work and it will surface three pieces of hidden coupling you did not know you had. That surfacing is most of the value. The suite that emerges is slower per run and dramatically cheaper per failure, because a red result now means something.
The decoy
A shared staging database that everyone’s tests point at. It makes the suite pass on a laptop, which is the thing people are trying to fix, and it couples every engineer’s results to every other engineer’s timing.
Evidence
- Reproducible Builds: Increasing the Integrity of Software Supply Chains — IIBit-for-bit identical builds are achievable at scale: over 95% of 30,000+ packages, verified by deliberately varying about thirty environmental parameters between two builds and diffing the result. Names the concrete non-hermetic causes found this way — embedded timestamps, filesystem ordering, locale-dependent hashing, build paths.
Seen in the wild
Anonymised field observation. Illustration, not evidence — these carry no tier and cannot raise one.
A test asserting a fixture against a live service turned every upstream change into a failure in code that had not moved. The suite was correct about something; it was not correct about the thing it claimed to test.
Last reviewed 2026-08-19.