Hermetic test

A self-contained test with controlled time, data, files, and services, so outside state cannot change the result.

“test with no internet”“test that works the same on every machine”“nothing outside the test can change it”“why does this pass on my laptop but fail in CI”“no shared database test”“hermitic test”“sealed off test”“test with its own clock and files”

What it is

A hermetic test controls every input it depends on: files, environment variables, time, randomness, services, and test data. It does not call the public internet or share mutable state with another test. Given the same code and declared inputs, it should produce the same result on a laptop and in CI. Bazel's sandboxed execution model is a well-known example of enforcing this boundary.

Reach for hermeticity when a suite passes alone but fails in parallel, depends on the office VPN, or changes with the date. A unit test can be hermetic with doubles; an integration test can also be hermetic when it gets a private, pinned database and controlled services for each run.

Gotcha: a Docker container does not make a test hermetic by itself. An unpinned image, a live package download, a shared volume, or the host clock still leaks outside state in. The opposite trap is mocking so much that the test no longer represents the real contract.

Ask AI for it

Make this Vitest suite hermetic. Replace direct `Date.now` and `Math.random` calls with injected clock and random-number interfaces, control time with `vi.useFakeTimers` and `vi.setSystemTime`, and use an Undici `MockAgent` installed with `setGlobalDispatcher`, then call `disableNetConnect()` so unexpected network calls fail immediately. Give each test a fresh directory from `mkdtemp`, provide all environment variables explicitly, restore globals in `afterEach`, and add a CI job that runs the suite twice in parallel to expose shared state.

You might have meant

test isolation setup and teardownunit testintegration testflaky testtest fixture