Logging Only on Failure

## Why a suite logs nothing until something breaks A REST Assured suite that calls `given().log().all()` on every request produces a complete transcript of every call it makes. On a green run that transcript is noise: hundreds of requests nobody will read, scrolled past on a shared CI runner. Switch logging off entirely and the opposite problem arrives — a case against the curling-ladder API fails at 02:00 and the job output holds a Hamcrest mismatch with no request beside it. **Failure-triggered logging** resolves both: REST Assured formats the log every time, holds it in memory, and emits it only for calls that actually failed. ## The two calls, one per side `ifValidationFails` is declared on `LogSpecification` — the half of the log DSL that the request side and the response side share — so the same three overloads exist on both: - `ifValidationFails()` — shorthand for `LogDetail.ALL`. - `ifValidationFails(LogDetail logDetail)` — narrow it, for example to `HEADERS`. - `ifValidationFails(LogDetail logDetail, boolean shouldPrettyPrint)` — the same, with pretty printing forced on or off. Which side you call it on decides which half of the exchange you get: | call | side | what it captures | |---|---|---| | `given().log().ifValidationFails()` | request | method, URI, params, headers, cookies, body | | `then().log().ifValidationFails()` | response | status line, headers, cookies, body | Neither call implies the other. A chain carrying only the response form leaves you staring at a ladder payload with no idea which rink id produced it, which is why the two are almost always written together. ## Turning it on for a whole suite Repeating both calls in every test is exactly the duplication a suite drifts out of. Two switches remove it: 1. `RestAssured.enableLoggingOfRequestAndResponseIfValidationFails()` — a static, usually called once in a `@BeforeAll` or a base class. The overload taking a `LogDetail` narrows what gets captured. 2. `LogConfig.enableLoggingOfRequestAndResponseIfValidationFails(...)` — the same setting reached through configuration, applied with `given().config(...)` or by assigning `RestAssured.config`. The static form is documented as a shortcut for exactly this. When the switch is on, REST Assured wires the buffered request log and the buffered response log while it builds the request — but only for a side that has no logging filter registered already. A request that carries its own `RequestLoggingFilter` keeps that one and does not get a second, buffered copy. ## What counts as "validation failed" This is the part that surprises people, and it is worth being literal about. The flush is driven by a **validation-failure listener** that REST Assured fires from inside its own response validation. It runs when an expectation declared in the `then()` chain — `statusCode(...)`, `body(...)`, `header(...)`, `contentType(...)`, `time(...)` — evaluates to a failure, and when a throwable escapes while those expectations are being evaluated. It does **not** run for: - a JUnit, TestNG or AssertJ assertion written after `extract()`, because that assertion is outside REST Assured entirely; - a connection or TLS failure that throws before `then()` is ever reached; - a status code on its own — status-driven logging is a different predicate from validation-driven logging, and the two do not fire at the same moments. So the rule of thumb is: if the assertion is inside the chain, the failure log fires; if you extracted first and asserted afterwards, it does not. ## A curling-ladder walk-through A case fetches `GET /rinks/{rinkId}/ladder` and expects the top rung to belong to skip `Aitken`. Both log calls are chained. On the happy path the service returns 200 with eight rungs, every expectation passes, and the job output stays empty. When the service quietly renames the field to `leadSkip`, the body matcher fails, and the console receives — in one block, request first — the method and URI including the resolved `rink-3` path parameter, every header that was sent, and the full response body that disagreed. That is enough to tell a contract change from a data problem without rerunning anything. ## What it costs and what it does not do - On a passing call the cost is building one string per side and letting it be garbage collected; nothing is written to the console. - It changes only what is **printed**. The request goes on the wire identically either way. - It is per-request state, not per-suite: each call gets its own buffer, and nothing leaks into the next test. - It captures what REST Assured built and sent, so it is the client's view of the exchange rather than the server's. - Chained by hand, the response-side call must sit **before** the assertions it is meant to explain, because a `then()` chain validates eagerly as each expectation is called. Used this way, failure-only logging gives a CI job the property people actually want from it: silence while everything works, and a complete, self-contained record of the one call that did not.