Response Logging on Failure

How it works

Request logging tells you what you sent; response logging tells you what the server said back, and for a failing API test that is usually the more useful half. After then(), log() returns a response log specification, and ifValidationFails() makes it print only when a later assertion in the same chain fails. Placed before the checks, it covers all of them.

The failure output is generous. When we expected the wrong category name for product 1, REST Assured printed the status line, every response header (rate-limit counters, Content-Type, the server name and more) and then the JSON body, pretty-printed with indentation, before the AssertionError. With a wrong user ID it showed the 404 status and the server's error message in the body, which explains the failure faster than any assertion text.

One detail of the error itself: when the status check failed on that 404, the assertion message reported one expectation, the status, even though the name check would also have failed. Fix the status problem first and the next run tells you about the rest.

About the assignment

Validate two different endpoints with response logging that only prints on failure, and print a confirmation line after each one passes.

What you will do

1. 1Send a GET for /users/1, then after then() call log().ifValidationFails() before the assertions.
2. 2In that chain, check status 200 with statusCode() and the name field with body() and equalTo(), then print the first confirmation line from the expected output.
3. 3Repeat for /products/1: same logging call, status 200, and a body() check on the nested category.name path against the expected category.
4. 4Print the second confirmation line after the product chain.

Common mistakes

• Checking the category object itself

  In the JSON product, category is an object with an id and a name. Comparing the whole object to a string fails; use the dotted path down to the name field.

• Printing without asserting

  If the chain stops at then() with no matchers, nothing is checked and the confirmation line proves nothing. The line should only be reachable after real assertions.

• Looking for logs on a green run

  Both requests pass here, so the console shows only your two lines. That silence is the feature; change an expected value temporarily to watch the log appear.

In a real test suite

Related lessons

• Conditional Request LoggingUses failure-only logging on the request side and extracts a value from the chain.
• Validate Nested JSONValidates nested JSON fields with dot paths such as the category name.
• Basic Response SpecificationMoves repeated status and body checks into a reusable response specification.

To try one of these calls on any API endpoint without a task, open the Online Selenium Java Compiler (REST Assured is included).

Starter code

The editor above opens with this code. Fill in the TODO lines, then run and submit it.

import io.restassured.RestAssured;
import io.restassured.response.Response;
import io.restassured.specification.RequestSpecification;
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;

public class Main {
    public static void main(String[] args) {
        RestAssured.baseURI = "https://testkru.com/api";

        // TODO: GET /users/1 with .then().log().ifValidationFails()
        // Validate statusCode(200) and body("name", equalTo("John Doe"))
        // Print "Response validation passed"

        // TODO: GET /products/1 with .then().log().ifValidationFails()
        // Validate statusCode(200) and body("category.name", equalTo("electronics"))
        // Print "Product validation passed"
    }
}