Response Time Validation

How it works

Every Response records how long the call took. getTime() and its alias time() return that duration in milliseconds as a long, and timeIn() with a TimeUnit converts it; for example, timeIn(TimeUnit.SECONDS) reports 1506 ms as 1. The figure is measured on the client, so it includes network time as well as the server's own processing.

testkru's /delay/{seconds} endpoint makes the measurement predictable. It sleeps for the requested whole number of seconds, capped at three, then returns delayed as an integer and a message describing the delay. A negative or non-numeric value gets a 400 instead. It is also rate-limited more tightly than the other endpoints, counted per client IP over a one-minute window, and a 429 comes back once that budget is spent.

Timing can be asserted directly. After then(), time() takes a Hamcrest matcher on a Long, so the threshold must be a long literal such as 2000L; an int literal does not compile. A breached limit produces an AssertionError stating the expected bound and the time actually measured.

About the assignment

Call the one-second delay endpoint, print the delay value it reports, and print whether the measured time exceeded one second.

What you will do

1. 1Send a GET for /delay/1 and keep the Response.
2. 2Read the delayed field with jsonPath().getInt() and print it after the Delayed: label.
3. 3Compare getTime() with 1000 using a greater-than check, and print the resulting boolean after the response-time label from the expected output.

Common mistakes

• Asserting an exact duration

  Two identical calls never take the same number of milliseconds. Test against a bound, greater than for a known delay or less than for an SLA, never with equality.

• Setting the ceiling too tight

  A threshold barely above your local timing will fail on a slower CI agent or network. Leave generous headroom; functional tests catch gross slowdowns, not small regressions.

• Running it in a tight loop

  Calling the delay endpoint repeatedly while experimenting spends its small per-minute allowance fast. After a 429, wait for the minute window to reset instead of retrying immediately.

In a real test suite

Related lessons

• Basic Response SpecificationBuilds a reusable response specification, a natural home for a time ceiling.
• Validate 200 OKAsserts the status code, the check that usually sits beside a timing check.
• Reading the Response BodyReads a single field from a JSON body, as done here for delayed.

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.*;

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

        // TODO: GET /delay/1
        // TODO: Print the "delayed" field from response
        // TODO: Check if response.getTime() > 1000 and print the result
    }
}