🔗 Test Chaining — Real E2E Scenarios

Test Chaining — Real E2E Scenarios: A chained API test works like a "kitchen tracking system" following a restaurant's order chain: you cannot send a produce-food request to the

A chained API test works like a "kitchen tracking system" following a restaurant's order chain: you cannot send a produce-food request to the kitchen before the table order has been entered, and you cannot take payment before the food has been delivered — every step must carry the state of the previous one. Is writing each test independently safer — why pass one test's output to another? Because the "create user → log in → add to cart → place order → delete" flow requires a real user session and real data at every step; testing with stubs means you miss combination failures like session timeouts or foreign key constraint violations. In Java, you build a similar dependency chain with JUnit's `@TestMethodOrder(OrderAnnotation.class)`; in REST Assured you carry a value from each step's response into the next request's header or body using `jsonPath().getString("id")` or `jsonPath().getString("token")`. The highest QA value: once you write this chain, at the end of every sprint you verify the full "happy path" flow with a single `mvn test -Dtest=E2EFlow` — zero manual click errors, zero reproduction time, step-by-step results visible in the CI report.

Full E2E CRUD Chain (reqres.in)

Micro Lab: REST Assured assertion writing

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

Step by Step: REST Assured assertion writing

Set base URL and auth with given()

Send the request with when().get/post/put/delete

Validate the HTTP code with then().statusCode()

Check JSON fields with body() and Hamcrest matchers

Include the test in JUnit/TestNG runner and CI pipeline

What is the order for writing and validating a REST Assured API test?

🎬 Test Chaining: One Test's Output, Another's Input

POST /users (create)

New ID (from response)