Description
The build was green, you deployed on a Friday, and Monday a client emails that their integration returns a field that used to exist and now does not. You check: every test passed. They always do, because your tests assert the status code and nothing else, and a 200 can be wrong in every way that matters. It handed a stranger another user’s record. It accepted input it should have rejected. It changed a response shape ten services quietly depend on. Clicking through Postman by hand catches none of this on the eleventh deploy, and the client is the one who runs the test you skipped. Testing an API well is a real discipline: knowing what to assert past the status code, checking the response against a schema, covering auth and the unhappy paths, and catching a breaking change with a contract test before anyone downstream ever sees it. The tools take an afternoon. Knowing what a correct API actually guarantees, and proving it on every commit, is the part that keeps the Monday email from arriving.
This book teaches you to test REST and GraphQL APIs like the contract they are, so a break is caught by your suite and not by a client in production. It starts from what to actually assert (the status code is the least of it: the response shape, the values, the headers, the side effects, and the errors) and builds a real suite from there. It covers validating a response against a JSON schema so a changed field fails loudly, testing the full method and status-code contract, exercising the unhappy paths and edge cases a happy-path click never reaches, and testing authentication and the per-object authorization holes (the request that returns another user data) that are the most common and dangerous API bugs. It goes practical with the tools the field uses, the request-and-assert workflow (Postman/Newman, a code-first approach with SuperTest or RestAssured, and Python with pytest and requests), data-driven tests across many inputs, and testing GraphQL where the single endpoint and flexible queries change what you assert. The hardest and most valuable chapters are about change over time: contract testing with a tool like Pact so a provider cannot break a consumer without the test failing first, and integrating the suite into CI so every commit proves the contract still holds. It closes on performance and security as the next layer and what those dedicated guides cover. The examples are a real API, shown with the bug a status-code check misses and the assertion that catches it. For engineers who want their API proven correct on every commit, not hoped correct.
Is this book for you?
This book is for: QA automation and backend engineers who have to prove an API is correct, stays correct as it changes, and does not break the clients that depend on it, and want a test suite that catches the break before a customer does.
What’s in this book
- Chapter 1: The green demo that shipped a broken API
- Chapter 2: What a passing test forgets to check
- Chapter 3: The renamed field that breaks every client
- Chapter 4: The promise every HTTP method quietly breaks
- Chapter 5: The inputs your demo never sent
- Chapter 6: The bug that hands a stranger someone else’s data
- Chapter 7: Postman or pytest, and when it stops mattering
- Chapter 8: One test for the cases you keep skipping
- Chapter 9: Why every GraphQL call says 200, even the failures
- Chapter 10: Two green suites, one broken integration
- Chapter 11: The suite that only runs when you remember
- Chapter 12: When a correct API still fails the user
- Chapter 13: Proven correct, not hoped correct
