Basic Response Specification

How it works

Request specs remove repetition from what you send. Response specs do the same for what you check. ResponseSpecBuilder collects expectations such as expectStatusCode(), expectContentType(), expectHeader() and expectBody(), and build() returns a ResponseSpecification. You apply it on the validation side with then().spec(), and REST Assured runs every expectation in it against the response.

The content-type expectation is forgiving in a useful way. ContentType.JSON matches a header of application/json followed by a charset=utf-8 parameter, so the charset suffix the server adds does not break it. Point the same spec at an XML endpoint, though, and it fails, and the message quotes the actual content type.

When several expectations fail at once, REST Assured does not stop at the first one. The AssertionError starts with a count, such as two expectations failed, and lists each broken rule, for example both a wrong status and a wrong content type. That makes a failed spec check quick to diagnose.

About the assignment

Define one response specification for a successful JSON reply, validate three collection endpoints against it, and confirm each validation.

What you will do

1. 1Create a ResponseSpecBuilder, add expectStatusCode() with 200 and expectContentType() with ContentType.JSON, then build().
2. 2GET /users and apply the spec with then().spec().
3. 3Print the confirmation for users, then do the same for /products and /books, printing a confirmation after each.

Common mistakes

• Calling spec() on the request side

  given().spec() expects a request specification, so a response spec there does not compile. Response specs belong after then().

• Packing endpoint-specific checks into the shared spec

  A spec that expects a name field fits users but not every collection. Keep shared specs to rules that hold for all responses, and add endpoint-specific body() checks after spec() in each test.

• Expecting a thrown exception to be returned

  A failing spec throws AssertionError, which stops the program at that line. There is no boolean result to test, so do not wrap the call in an if statement.

In a real test suite

Related lessons

• Combined Request and Response SpecsUses a response spec together with a request spec in one chain.
• Combined SpecificationRepeats status checks by hand that a response spec can absorb.
• Response Time ValidationAdds a response-time check, a common extra rule in shared specs.

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 io.restassured.http.ContentType;
import io.restassured.specification.ResponseSpecification;
import io.restassured.builder.ResponseSpecBuilder;
import static io.restassured.RestAssured.*;

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

        // TODO: Create a ResponseSpecification expecting status 200 and ContentType.JSON
        // TODO: Validate /users, /products, and /books against this spec
        // TODO: Print confirmation after each
    }
}