In unittest, how does TestCase.subTest label which case failed?

## The label is the whole value of the feature Per-case reporting is only useful if a reader can tell *which* case each entry refers to. `unittest.TestCase.subTest` builds that label from what you pass it, and passing nothing is the most common way to waste the feature. The signature takes an optional positional message first, then arbitrary keyword parameters: ```python with self.subTest("locale row", region="de", text="1,5"): ... ``` The sub-result's description is assembled as: the message in square brackets when given, then the parameters in parentheses as comma-separated `name=value` pairs, with each value rendered by `repr`. The full identifier is the parent test's id followed by that description, so a failing entry prints as something like: ``` FAIL: test_parse (pkg.tests.QuantityTest.test_parse) [locale row] (region='de', text='1,5') ``` When you pass neither a message nor parameters, the description collapses to the literal placeholder `(<subtest>)` — every failing case in the loop then produces an identical-looking header, and you are back to reading tracebacks to work out which row broke. ## Why repr, and why it matters Values are formatted with `repr`, not `str`. That is deliberate: it is what makes `'1,5'` visibly different from `'1.5'`, makes an empty string visible at all, and distinguishes `1` from `'1'` and from `True`. Anywhere the difference between two inputs is a delimiter, a trailing space, or a `str`/`bytes` distinction, `str` formatting would render the two rows identically and the label would lie. The flip side is that `repr` of a large object is a wall of text in the middle of the report. Pass identity, not payload: ```python for case in CASES: with self.subTest(case_id=case["id"]): check(case) # the whole case dict stays out of the label ``` ## Building the case table as data The label question and the table question are the same question, because the label is drawn from the table's identifying columns. A workable shape is a module-level or class-level sequence of dicts or `namedtuple`s where one field is a stable, human-meaningful id: ```python Row = collections.namedtuple("Row", "id text expected") ROWS = [ Row("plain", "1.5", 1.5), Row("comma", "1,5", 1.5), ] class ParseTest(unittest.TestCase): def test_rows(self): for row in ROWS: with self.subTest(row=row.id): self.assertEqual(parse_qty(row.text), row.expected) ``` Three properties make this table hold up in review. The ids are stable, so a failure in CI logs is greppable and a flaky row can be named in a ticket. The loop body is one assertion, so the reader sees the *rule* being checked once rather than repeated per row. And the table is ordinary data, so it can be extended by someone who has never read the test framework's documentation — which is usually the point of writing it this way. `self.subTest(**case)` is tempting when the table is a dict of small scalars, and it is fine there; it stops being fine as soon as one column is an object, a long fixture string, or a value that is expensive to `repr`. ## The case label and an assertion message are different strings Two strings compete for the same job and land in different places. The positional argument to `subTest` labels the *case*: it appears once in the sub-result's header, whether the case ended in an assertion failure or an unexpected exception. The `msg=` keyword accepted by the assertion helpers labels the *assertion*: it appears inside the failure body, appended to the standard diff. A loop that checks three properties per row usually wants both — the row id on the `subTest`, and a short `msg=` on each assertion naming which property broke. Passing the row id to every assertion instead leaves the header anonymous and repeats the same string three times in the body. ## What the label does not do The label is a display string, not an addressable name. You cannot rerun one case by dotted path the way you can rerun a test method, because there is no method to name — the selection unit is still the method. If a particular row must be individually runnable, skippable, or excludable from CI, that is the signal to generate real test methods from the table instead, at the cost of a factory a reader has to decode. And note the message is a *label*, not an assertion message: the `msg=` argument you pass to an assertion helper is separate and still appears in the assertion's own output. ## Interviewer's angle The question separates people who have merely seen the idiom from people who have read a failing report at three in the morning. Mentioning `repr` rendering and the `(<subtest>)` placeholder is the concrete detail that shows the second.