How does assertAll behave with nested assertAll groups, and what are the precise semantics of its single-vs-multiple-failure reporting?

## Precise reporting semantics `assertAll` (org.junit.jupiter.api.Assertions) iterates the supplied `Executable`s, invoking each and catching any `Throwable` into a list. Then: 1. **Zero failures** -> returns normally; the test passes. 2. **Exactly one failure** -> it **rethrows that original Throwable unchanged**. An `assertEquals` mismatch surfaces as the same `AssertionFailedError` (a subclass of `AssertionError`) you would get without assertAll; a stray `NullPointerException` surfaces as that NPE. There is no wrapping when only one thing failed. 3. **Two or more failures** -> it throws a single **`MultipleFailuresError`** (from the **opentest4j** library, the shared test-result API JUnit 5 builds on). This error holds the list of collected failures; the test report renders each with its own message and stack trace. Key nuance: assertAll catches **any `Throwable`**, not just `AssertionError`. If a lambda throws a `NullPointerException` or `IndexOutOfBoundsException`, that is collected as that check's failure — which is precisely why dependent checks (where a later lambda blows up because of earlier state) are a poor fit. ## Nesting assertAll Because each argument is an `Executable` (a lambda), and a lambda can contain *any* code, a lambda may itself call `assertAll`: ```java assertAll("address", () -> assertAll("home", () -> assertEquals("NYC", home.city()), () -> assertEquals("10001", home.zip())), () -> assertAll("work", () -> assertEquals("SF", work.city()), () -> assertEquals("94105", work.zip())) ); ``` How it composes: the inner `assertAll("home", ...)` runs its two checks. If both inner checks fail, the inner call throws a `MultipleFailuresError`; **from the outer assertAll's perspective that inner error is simply the Throwable thrown by the "home" Executable**, so it is collected as one failure of the outer group. The outer report therefore nests the inner group's failures under its heading. Nesting is a way to **organize related sub-checks** and keep large verification blocks readable, with headings forming a path. ## Execution model - **Sequential, single-threaded:** assertAll runs the lambdas in order on the calling thread. There is no parallelism, no reordering, no retry. - **Always runs every lambda:** there is no early exit. This is the defining property and the source of both its benefit (full failure picture) and its hazard (no short-circuit for dependent checks). - **Stream overload:** besides varargs and `(String heading, Executable...)`, there are overloads accepting `Collection<Executable>` and `Stream<Executable>`, useful for generating checks dynamically (e.g. one per item). ## Design-level implications - Prefer **several headed groups / nested groups** over one flat grab-bag so the failure tree maps to your domain structure. - Treat assertAll as an **aggregation primitive, not control flow.** If correctness of check N depends on check N-1, use sequential asserts or split the test; do not rely on assertAll to stop. - The **single-failure-rethrow** rule means tooling and custom failure handlers see the genuine assertion error when only one thing is wrong — assertAll does not obscure the common case. ## Terms recap - **Executable:** JUnit 5 functional interface, `void execute() throws Throwable`. - **AssertionFailedError:** opentest4j error a failed JUnit assertion throws (subtype of AssertionError). - **MultipleFailuresError:** opentest4j aggregate thrown when assertAll has 2+ failures. - **opentest4j:** the open testing result library JUnit 5's assertions are built on.