A unittest test passes alone but fails under `python -m unittest discover` — how do you diagnose it?

This is a leak diagnosis, and the shape of the evidence tells you that before you read a line of the test. ### Why discovery changes the outcome `python -m unittest discover` does not fork or isolate anything. It walks the tree, imports every matching module into one interpreter, builds a single `unittest.TestSuite`, and runs it in that same process. Three consequences follow: 1. **Module state is process-global.** Anything created at import time or memoised in a module-level or class-level variable lives for the whole run. A payroll importer that caches its rate table on first use serves that same object to every later test. 2. **Modules are imported once.** `sys.modules` caches them, so a later module doing `import payroll.rates` gets the already-warmed object, not a fresh one. "Just re-import it" is not a fix. 3. **Order is deterministic but fragile.** Directory entries are walked in sorted order and method names within a `unittest.TestCase` are sorted too, so the run is repeatable on a given tree — but adding a file changes the order, which is exactly why the failure appeared on an unrelated commit. The usual culprits, roughly in order of frequency: a memoised lookup or connection pool at module scope; monkeypatching that is never undone; a class attribute mutated by an instance; environment variables set for one test; the working directory changed and not restored; and a logging or warnings filter installed once. ### The bisect, concretely Take a payroll CSV import whose loader resolves pay rates across a 17-service dependency graph and caches the resolved table on first import. - **Confirm the baseline.** `python -m unittest tests.test_csv_import.CsvImportTests.test_uses_current_rate` on its own passes. Good — the test is not simply wrong. - **Reproduce the pair.** Test names are positional and honoured in order, so `python -m unittest tests.test_rate_cache tests.test_csv_import -v` runs a candidate polluter followed by the victim. If it fails, you have a two-line reproduction instead of a whole suite. - **Prove it is order, not content.** Swap the two names. A failure that moves or disappears when the order changes is pollution by definition. - **Narrow within the module.** `-k` filters by name and may be repeated, so you can whittle the polluter down to a single method. - **Stop at the first failure.** `-f` ends the run on the first failure or error, which keeps output short and prevents a cascade of secondary failures from obscuring the first real one. - **Silence the passing tests.** `-b` buffers stdout and stderr per test and prints the buffer only for a test that fails or errors. That is doubly useful here: not only is the noise gone, but any output attributed to the failing test that was actually *produced* by setup done earlier stands out. - **Read the ids.** `-v` prints each test's full dotted name, which is both the running order and the exact string to feed back into the command. ### Verifying the hypothesis Once you suspect a specific cached object, inspect it rather than guessing: assert its identity or its contents at the top of the failing test and watch it already be populated. If the object is created at import time, the value will be there before any of your setup ran, which is conclusive. ### Fixing it, and what not to do The right fix removes the sharing. Build the expensive thing inside the test and dispose of it afterwards, or expose an explicit reset the test can call, or inject the cache rather than reaching for a module global. If the object is genuinely expensive, a per-class or per-module fixture with a matching teardown keeps the cost down without leaking across modules. What not to do: rename files to force a convenient order, or pin the run to a sequence that happens to pass. That converts a real defect into a booby trap that fires the next time someone adds a test — and the standard library runner offers no supported ordering knob to lean on anyway. Equally, do not reach for one process per test file as the primary answer; it hides the coupling rather than removing it, slows the suite, and the shared state is usually still wrong in production code that runs the same way. ### What to say in an interview Lead with the mechanism — one process, one `sys.modules`, shared module state — then the two-command reproduction, then the bisect flags, then the fix that removes the sharing. Naming `-f`, `-b` and `-k` in the right roles shows you have actually worked a flaky suite rather than read about one.