Explain how Gradle's HTML test report relates to the binary test results, and why you can regenerate the HTML without re-running the tests.

## The binary result store The primary thing a `Test` task produces is **not** the HTML — it's a set of **binary result files** recorded as tests execute (historically under `build/test-results/<task>/binary/`). Each test class/method outcome, duration, and captured stdout/stderr is serialized there. ## Renderings are derived At the end of the task Gradle renders two human/tool-facing views from that binary data: - **HTML** → `build/reports/tests/<task>/index.html` (for people) - **JUnit-XML** → `build/test-results/<task>/TEST-*.xml` (for tools) Both are *downstream* of the binary store. That's the key architectural fact. ## Consequences 1. **Independent toggles** — `reports.html.required` and `reports.junitXml.required` switch the two renderings on/off independently; the binary data underneath is unaffected. 2. **Regeneration without re-running** — because the binary results persist, the HTML can be produced again from them. You don't need to pay the cost of re-executing tests just to get a fresh report. 3. **Aggregation** — the `test-report-aggregation` plugin / `TestReport` task consumes binary results from multiple test tasks (even across subprojects) and emits one combined HTML report. This only works because results are stored in a recombinable binary form, not pre-baked into per-task HTML. ## Practical note Because the HTML is a finalizing render, an `UP-TO-DATE` test task keeps the previously generated report and XML — they're valid as long as the binary results behind them are unchanged. A `clean` wipes everything since it deletes `build/`. ## Why interviewers ask this It separates people who memorized paths from people who understand that Gradle's reporting is a *pipeline*: execute → record binary → render HTML/XML → optionally aggregate. That mental model explains aggregation, independent toggles, and cheap regeneration in one stroke.