In an Allure report, one failed class-level setup shows up as the same failure on ten different test case pages. How does the container model produce that, and what must you not conclude from it?
answer
- one object, many pages
- stored once, attributed many times
- compare the timestamps across pages
- children length is the blast radius
- one failure, not ten
basics
~20 sOne container holds the failed fixture once in its befores and names ten children, so the reader attributes the same FixtureResult to each of them. Do not read it as ten setup runs, ten failures, or ten times the duration.
solid answer
~40 sThe fixture ran once. It is stored once, as a single `FixtureResult` in one container's `befores`, and that container's `children` lists the uuids of ten cases. During generation the reader folds the same object into each of those cases' before-stages, so ten pages render an identical failure with an identical message and an identical `start`/`stop` pair. What you must not conclude is multiplicity: not ten executions, not ten independent failures, and not ten times the elapsed time. It is one event, shown ten times, because the model records *membership* rather than copying the fixture per case. The tell is the timestamps — identical `start` and `stop` values across pages mean one run, whereas ten real executions would have ten distinct intervals.
go deeper
Recognise that the same setup failure repeated across many case pages usually means one shared fixture, not one problem per case.
Explain the mechanism: one FixtureResult in one container's befores, a children list of uuids, and a reader that folds that single object into every case it names.
Act on it under pressure — treat the run as one incident, read the blast radius off children, and refuse any count or duration total built by summing the repeated pages.
Judge what this shape costs downstream: any consumer aggregating per-case fixture data double-counts a shared event unless it deduplicates by container.
## What the directory actually contains When a class-scoped setup fails and ten case pages show it, the results directory usually holds far less than the report suggests: - **one** `-container.json`, whose `befores` holds **one** `FixtureResult` with a failed status, a message and trace in its `statusDetails`, and a single `start`/`stop` pair; - **ten** `-result.json` files, whose uuids appear in that container's `children`. Nothing was duplicated on disk. Generation is a join: each child uuid named by the container receives that container's fixtures in its before-stages. Ten pages, one object. ## Why the model does it this way A fixture is shared by construction — that is what a class or suite scope means. The container records two separate facts, and it is worth keeping them apart when reading a report: 1. **What happened** — one fixture, one status, one interval, held once in `befores`. 2. **Who it applied to** — a list of uuids in `children`. The report answers a per-case question ("what surrounded *this* test?"), so it must project fact 1 across fact 2. The projection is presentation. It is not evidence of repetition. ## What you must not conclude | the page suggests | the model actually says | |---|---| | ten setup executions | one execution, attributed to ten cases | | ten distinct failures to triage | one failure, one message, one trace | | ten times the fixture's duration spent | one interval, counted once | | each case independently hit the problem | membership in one scope, nothing more | | ten separate things to fix | one root cause upstream of all ten | The practical damage is in aggregation. Anyone summing the durations on those ten pages inflates the run's setup cost tenfold. Anyone counting "failures containing this message" gets ten where the run produced one. Anyone bucketing failures by message will find one enormous bucket that is really a single event. ## How to tell attribution from repetition The distinction is checkable, and these are the checks worth knowing: - **Compare `start` and `stop` across pages.** Identical values mean one shared object projected onto many cases. Genuinely repeated setup produces distinct, non-overlapping intervals. - **Count container files, not pages.** One `-container.json` naming ten children is attribution; ten containers with one child each is repetition. - **Look at where the fixture sits.** A per-method setup appears as one fixture in one small container per case; a class-scoped one appears once in a wide container. - **Check `children` length.** It is the fan-out factor of everything that container contains. ## Reading the failing run correctly When you see the pattern, the ordering of your investigation follows from the model: 1. **Treat it as one incident.** Open one page, read the fixture's `statusDetails` — message, trace, and where present the actual/expected pair — and work from there. 2. **Establish scope from `children`.** The uuid list is the exact blast radius: those cases and no others were covered by the fixture. 3. **Ignore the multiplicity in any count you report.** The number of affected cases is real; the number of failures is one. 4. **Do not confuse an absent case with a covered one.** A case whose uuid is not in `children` was never in that scope, however similar its name looks. ## The mirror image in the other shape Where fixtures are typed nodes in a single tree rather than sidecar objects, the same shared setup usually appears **once**, as one node with one status, and the affected cases are its siblings or descendants rather than pages carrying a copy. That is the reverse tradeoff: the multiplicity illusion disappears, but nothing on a case's own node tells you what ran before it — you have to walk up the tree to find out. Neither shape lets you skip the question; they simply put the work in different places.
- How would you prove from the results directory that the fixture ran once rather than ten times?Count container files. One `-container.json` whose `befores` holds a single `FixtureResult` and whose `children` lists ten uuids is one execution attributed ten times. Ten separate containers with one child each would be ten executions, and their `start`/`stop` intervals would differ.
- Does the same illusion affect the report's duration figures?It affects any figure you compute by summing per-page fixture durations, because the same interval is shown on every covered page. The fixture's own `start` and `stop` are recorded once in the container, so read the elapsed time from there rather than adding up what the pages display.
saying these in an interview costs you the question
- Counts one shared fixture failure as ten failures
- Sums the same fixture duration across every page
- Assumes each case re-ran the setup independently
- Opens ten pages expecting ten different traces
- Ignores children when scoping the blast radius