Testing APIs and data
Almost everything the Mangrove app does on screen is a request to an API and a row in a database. When you test at that level, a check takes about a second instead of a couple of minutes, and you see exactly what the server said and saved. This lesson shows you how, with an API client, curl and a few lines of SQL.
By the end you can
- Read a request and a response, and know which status code a correct API should give for each situation
- Check a response properly: status, headers, body shape and types, values, time, error format and leaked fields
- Design negative tests for an API: missing fields, wrong types, boundaries, duplicates, wrong state and someone else's data
- Check the database after an action with SQL, and keep test data under control
- Build a small order API collection with assertions that runs the same way every time
The everyday picture
Think of a busy restaurant. You want to know if the kitchen gets orders right. One way is to sit at a table, wait for a waiter, order, and wait for the dish. That is slow, and when the dish is wrong you cannot tell who made the mistake: the waiter, the ticket or the cook.
The other way is to stand at the kitchen pass and hand the cook a ticket yourself. You see the exact ticket, the exact plate that comes back, and how long it took. Then you open the stock book and check that the right ingredients were taken off the shelf. The ticket is the request, the plate is the response, and the stock book is the database. API testing is standing at the pass.
Why test below the screen
The Mangrove app on a customer's phone is mostly an API client. When a customer taps "Place order", the app sends one request to the order API, and the API does the real work: it checks the cart, prices every line, adds the delivery fee, applies FRESH10, reserves stock in the store and saves the order. The app then draws whatever the API sent back. So most checkout bugs live in the API, and you can reach them directly.
Testing there has three big advantages. It is fast: tapping through checkout by hand takes a couple of minutes, while an API call to the test environment usually answers in well under a second, so you can run a hundred cases in the time one manual run takes. It is precise: you see the exact status code, the exact numbers and the exact error, with no screen in between that rounds 2440 cents to "$24.40" and hides a wrong type. And it reaches what the screen blocks: the app's quantity stepper stops at 20, but nothing stops another client, an old app version or an attacker from sending 21, or 0, or "two". The API is the real gate, so the API is where the rules must hold.
API tests sit in the middle of the testing pyramid that developers know from Errors, debugging and testing. They do not replace a few end-to-end runs on real phones (the screen can still be broken), and they do not replace the risk thinking from What testing is for. They make most of your checks cheaper.
Quick check
Which problem is much easier to find with an API test than through the app's screens?
The app never lets you send a quantity of 0, so through the screen the bug is invisible. Any other client can send it, and only a direct API call shows that the server accepts it. The button and the font are screen problems that an API test cannot see at all.