When a REST Assured expectation fails, what is thrown and how does JUnit 5 or TestNG see it?

## Where the AssertionError is born Every expectation you attach in `then()` — a status code, a status line, a header, a cookie, a content type, a response time, a body path — is recorded on REST Assured's internal response specification and then checked against the response. When the checks produce mismatches, that class does exactly one thing: ```groovy throw new AssertionError("$numberOfErrors expectation$s failed.\n$errorMessage$formattedOnFailMessage") ``` That is `java.lang.AssertionError`, the JDK's own type, constructed with a message string and nothing else. There is no REST Assured exception hierarchy for validation, no error code, no structured payload and no callback. ## What the message contains The message has a fixed shape, and reading it at a glance is a real skill on a red build: - It opens with a count and a pluralised noun: `1 expectation failed.` or `3 expectations failed.` - Under that comes one block per mismatch. A body-path mismatch reads `JSON path <path> doesn't match.` followed by `Expected:` and `Actual:` lines; status code, status line, content type and response time each have their own wording. - An `onFailMessage` you supplied is appended at the very end. A failing turbine assertion therefore reaches CI looking like this: ```text java.lang.AssertionError: 1 expectation failed. JSON path state doesn't match. Expected: SPINNING Actual: FEATHERED ``` ## How the runner finds out: it doesn't, you throw at it There is no integration. REST Assured never registers a listener, never calls a reporting API and never names a runner. Both JUnit 5 and TestNG invoke your test method reflectively and record whichever throwable escapes it; "throw and let it unwind" is the one contract every JVM runner honours, and it is the entire handoff. That is why the library needs no adapter for JUnit 4, JUnit 5, TestNG or anything else: it never learns which of them is running, and it never needs to. - The library has no `@Test`, no lifecycle hooks and no result model of its own. - Its main sources contain no reference to JUnit, TestNG or opentest4j. `junit-jupiter` appears in its build only at test scope, for testing the library itself. - Consequently the same `given()...then()` chain compiles and fails identically under either runner. ## The Groovy boundary, and why you never see it REST Assured's request implementation is written in Groovy, and every verb method — `get`, `post`, `put`, `delete`, `head`, `patch`, `options` — wraps its work in `GroovyAssertBridge.runWithUnwrap`. Groovy and reflective dispatch like to wrap the real cause in `GroovyRuntimeException`, `InvocationTargetException` or `UndeclaredThrowableException`; the bridge unwraps those containers recursively and rethrows the original throwable, using a sneaky throw so the method signature does not change. Without it your CI report would show a Groovy wrapper with the interesting failure buried two `Caused by:` levels down. With it, the `AssertionError` — or the real transport exception — is the top-level throwable the runner records. ## Not everything that fails is an AssertionError | What went wrong | What leaves the library | |---|---| | an expectation did not match | `java.lang.AssertionError` | | no object mapper on the classpath | `IllegalStateException` | | a named object mapper is absent | `IllegalArgumentException` | | the turbine service is unreachable, or TLS fails | the transport's own exception, unwrapped | That distinction is the practical half of the answer. A red build full of `AssertionError` is a build whose assertions ran and disagreed with the service; a red build full of `IllegalStateException` is a build whose classpath or environment is wrong, and no amount of staring at the turbine API will explain it. What a report calls each category afterwards is the runner's and the reporting tool's business, not the library's. ## What this design buys, and what it costs - **Portability.** JUnit 4, JUnit 5, TestNG, Spock or a bare `main` method all work, with no adapter module per runner and no version matrix to maintain. - **Predictability.** One failure produces one throwable, at one point in the chain, with a message you can grep for in a log. - **A real cost.** Because it is a bare `AssertionError` rather than an opentest4j `AssertionFailedError`, there are no machine-readable expected and actual fields for an IDE to render as a side-by-side diff. Everything a tool can show you is inside the message string, which is precisely why REST Assured invests so heavily in request and response logging.