03 /Test Automation
API Test Automation
Automated coverage at the service layer, where a check finishes in a fraction of a second and a failure names one component instead of a page. Much of what teams verify through a browser is really a statement about data, and moving those checks down is the cheapest way to bring a pipeline suite back inside its time budget.
What you get
Contract and schema assertions
Automated checks that each response still matches the shape its consumers depend on: types, required fields, nullability and error bodies. A field quietly changing from a string to an object reaches production precisely because the status code is still 200.
The states a browser cannot easily reach
Refused roles, malformed payloads, expired tokens, concurrent writes and the same request arriving twice. These are trivial to produce at the service layer and awkward to stage through an interface.
Test data built through the API itself
Each test creates the records it needs and removes them afterwards using the same endpoints your consumers call. A useful side effect is that the setup path ends up under test, which is where a surprising share of defects turn out to live.
Suites shaped for unattended running
Written to execute headless, in parallel, against a configurable base URL, so the same tests serve a developer machine and the pipeline without edits. Failures arrive with the request and the response body attached.
Authorisation negatives, asserted not assumed
For every protected route, the case that should be refused is encoded alongside the case that should succeed. It is cheap to write once and it is the check most likely to catch a regression introduced by a refactor of your permissions code.
How it runs
- 01
Agree the surface
We list the endpoints worth maintaining tests for and the consumers each one serves, marking those whose failure would otherwise be silent. Not every route earns a maintained test, and an internal endpoint called once a quarter rarely does.
You provide: A specification or collection, credentials for each role, and an environment that can be reset
- 02
Stand up the harness
Base configuration, authentication handling, data builders and one endpoint covered properly. Token handling in particular gets solved once, because sign-in logic reimplemented in every file is a tax paid on each subsequent change.
We produce: A running harness with one endpoint covered · Reusable data builders
- 03
Cover contracts and failures
Assertions are written across the agreed endpoints, positive and negative, with schema checks wherever the contract is stable enough to hold one. Anything that turns out to be genuinely undefined is raised with you rather than silently encoded.
We produce: The automated service-layer suite · A list of contract ambiguities found on the way
- 04
Run it where it counts
The suite joins your pipeline as the fast tier, ahead of anything driving a browser, so a broken contract fails in seconds rather than after a full end-to-end run has finished.
We produce: A pipeline job for the service tier · Reporting configuration
Where this stops
- Not load testing. These suites assert correctness one request at a time; how a service behaves under sustained concurrency is measured with different tools in a controlled environment.
- Not a replacement for the browser tier. Rendering, routing and anything existing only in the client still needs a real browser, and a service suite passing while the page is blank has told you nothing.
- Not consumer-driven contract testing as a governance programme. Automating expectations is straightforward; running a broker and enforcing a versioning policy across teams is an organisational commitment rather than a suite.
- Not documentation as a deliverable. The suite will expose where your specification is wrong, and correcting it stays with the team that owns the service.
Related reading
- Test automation
CI test gating: deciding what a red build is allowed to stop
Wiring a suite into a pipeline takes a day. Deciding what it may block is the real project, and it is a social agreement with a configuration file attached.
- Test automation
Diagnosing flaky tests: a procedure, not a retry
A retry policy converts an unreliable suite into a slow one that sounds confident. Four families of flake, the tell that identifies each, and the order to work through them.
- Test automation
Test data management: five strategies and what each one costs
How a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
FAQ
API Test Automation questions we hear often
We already have Postman collections. Is that not automation?
It is a good starting point and it is not the same thing. A collection is run by a person who remembers to run it; automation executes on every change, fails a build, and reports without being asked. Collections also tend to accumulate hard-coded identifiers and a shared environment, and both have to go before anything can run unattended.
How much should sit at the service layer rather than in the browser?
As much as can honestly go there. Anything whose truth is decided by the server, which covers most business rules, belongs at this level: it runs faster, it fails more precisely, and it survives a designer moving a button. Reserve the browser for what genuinely requires one. Getting that ratio wrong produces a suite too slow to gate anything.
Can you automate tests against a GraphQL API?
Yes. The assertions move from status codes onto the error array and the resolved data, and the interesting cases become field-level permissions, nested queries, and what an unauthenticated caller can learn from introspection. The structure of the suite is otherwise familiar, and it is often easier because a machine-readable schema can drive the checks.
What happens when the API changes?
The suite fails, which is the entire point, and somebody decides whether the change or the test is wrong. Keeping that decision cheap is a design goal: requests are assembled behind builders so a newly required field is added in one place, and schema assertions cover what consumers actually depend on rather than every field the service happens to return.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.