Why can a failure inside unittest's TestCase.subTest still abort the loop?

## The guard is smaller than the loop `unittest.TestCase.subTest` protects the statements inside its `with` block and nothing else. The distinction is easy to lose when the block is the body of a loop, because the loop *looks* fully wrapped: ```python for text in rows: value = float(text) # unguarded with self.subTest(text=text): self.assertGreater(value, 0) ``` If a row makes `float(text)` raise, the exception escapes the method: one error is reported against the method, later rows never run, and the report names no row at all. The fix is to pull the work inside the block — which is also the right shape for a different reason, since a case that cannot even build its input is a case that failed. Any helper called between cases, and the loop's own iterator, live in the same unguarded space; a generator that raises while producing the next row aborts the method just as surely. ## Fail-fast turns the isolation off on purpose Fail-fast mode — `python -m unittest -f` / `--failfast`, `unittest.main(failfast=True)`, or the `failfast` argument to a runner — stops the run at the first failure. It applies to subtests too: after a case fails, `subTest` sees the fail-fast flag on the result and stops the enclosing method rather than continuing the loop. This is not a bug and not an interaction to work around; it is what fail-fast means. It does explain a confusing report, though: the same table yields three failing rows locally and one in a CI job configured with `-f`, and nothing about the code changed. When someone says "subtest reporting is broken on CI", the runner flags are the first thing to read. ## A result object that does not support subtests Per-case reporting is negotiated, not assumed. `subTest` checks whether the active result object provides an `addSubTest` method; if it does not — a hand-rolled `TestResult`-like class, an old integration shim between unittest and another reporting tool — then `subTest` simply yields with no executor around the body. The `with` block then does nothing whatsoever: the first failing assertion propagates and the method ends as if you had written a plain loop. The important part is that this degradation is **silent**. No warning is emitted, no attribute error is raised, and the code reads exactly like a working per-case loop. `unittest.TestResult` and the standard runners implement `addSubTest`, so the plain path is safe; the trap belongs to bespoke reporting integrations. The same pass-through applies when there is no active outcome at all — `subTest` used outside a running test does nothing rather than failing loudly. ## KeyboardInterrupt is deliberately not caught The executor around a subtest body catches everything except `KeyboardInterrupt`, which is re-raised. That keeps Ctrl-C working on a long-running table: without the exemption, an interrupt would be recorded as one more failing case and the loop would carry on to the next row, which is precisely the behaviour that makes people reach for `kill -9`. ## Widening the guard When the unguarded work is per-row — building the input, normalising a value, opening the fixture that row needs — the fix is not a wider `try` around the loop but moving the work inside the block: ```python for row in rows: with self.subTest(row=row.id): value = parse(row.text) # a row that cannot be built has failed self.assertGreater(value, 0) ``` A row whose input cannot even be constructed *is* a failing row, and reporting it as one is more honest than aborting the method and blaming nothing in particular. The work that legitimately stays outside the block is work shared by every row — and if that shared work is fragile enough to raise, it belongs in `setUp`, where the failure is reported as a fixture error against the method instead of being mistaken for a data problem in whichever row happened to be next. ## What to take from this The mental model to carry is that `subTest` is a *guard around a block* whose effect is negotiated with the result object and can be overridden by the runner — not a property of the loop. So when a table reports fewer cases than it has rows, work down three questions in order: is the failing work actually inside the block; is the run in fail-fast mode; and is the result object a standard one. Two of those three are visible without touching the test file at all, which is why this is a cheap diagnosis to run first.