How do you make code that draws from Python's random module reproducible in a test?

### The module-level functions are one shared object `random.random()`, `random.choice()`, `random.shuffle()` and their siblings are not independent functions. At import time the `random` module constructs a single hidden `random.Random` instance and exports its bound methods under those names. Every caller in the process — your code, the code you imported, a library's import-time initialisation — draws from that one generator and advances its state. That is why `random.seed(0)` inside a test is not the isolation move it looks like: it mutates a process-wide object, and anything that draws a number between your seed call and your assertion shifts the sequence you are about to compare against. Change an unrelated import, or run the tests in a different order, and the "deterministic" expectation moves. ### Own your generator The fix is the ordinary dependency-injection move: create your own generator and pass it in. ```python import random def plan_restarts(stops, attempts, rng=None): rng = random.Random() if rng is None else rng return [rng.sample(stops, len(stops)) for _ in range(attempts)] ``` Production passes nothing; the test passes `random.Random(20260903)` and gets the same restarts every run, no matter what else the process did. Two tests that each construct their own `random.Random` cannot interfere with one another, which is exactly the property `random.seed()` fails to give you. If the code is already written against the module functions, patching the name the module imported is a valid stopgap, but an `rng` parameter is cheaper to reason about and shows up in the signature. ### What the same seed actually guarantees CPython documents a narrow but useful promise: the algorithms and seeding functions may change between versions, but a compatible seeder will always be offered, and `random()` will keep producing the same sequence for the same seed. So a bare stream of `rng.random()` values is stable. The *derived* helpers are not covered by that promise, and they have moved: `random.shuffle()` lost its optional per-call random-source parameter in 3.11, and `random.sample()` stopped accepting sets in 3.11. The lesson for tests is to avoid pinning golden literals produced by `shuffle`, `sample` or `choices` across interpreter upgrades. Assert the properties you actually care about — the permutation contains every input exactly once, the chosen index is in range, two runs with the same seed match each other — and reserve exact literals for the same interpreter that produced them. ### Seeds you can read An integer seed is the usual choice, but `random.Random` also accepts `str`, `bytes` and `bytearray` seeds, hashed internally, which lets a test seed itself from a meaningful label. When a test deliberately generates a fresh seed to widen coverage, print or attach it on failure: an unreproducible random failure is worse than no coverage at all. ### The traps `random.SystemRandom` draws from the operating system entropy source, so seeding it does nothing — its `seed()` is a no-op and its output can never be reproduced. That is a feature where you want unpredictability and a silent defeat where you wanted determinism. In the other direction, the Mersenne Twister behind `random` is not cryptographically secure: given enough consecutive outputs its future output is predictable, so tokens, password resets and nonces belong to the `secrets` module regardless of how the tests are written. Restoring state with `random.getstate()` and `random.setstate()` is occasionally proposed as an isolation mechanism for the global generator. It works, but it is a manual save/restore around shared mutable state — the same shape of problem an injected generator removes entirely. ### Determinism is not the same as coverage A single fixed seed makes a test repeatable; it does not make it thorough. A route-planning heuristic that only ever sees the restart order produced by seed 20260903 is tested against one sample of its input space. The mature pattern is a fixed seed for the regression tests that must never flap, plus a separate, deliberately-varying run that records its seed so any failure it finds can be turned into a fixed-seed regression test. Keep the two kinds of test apart: mixing them produces a suite that is neither reliably green nor genuinely exploratory.