The five activities inside API testing
Functional. Does one endpoint do the right thing, including with bad input. Start here. Everything else assumes it.
Integration. Do sequences produce the right outcome. Where most user-visible bugs actually are.
Contract. Do two services agree on the shape. Valuable with independent deployments, blind to correctness.
The other two are load, which answers capacity and needs a dedicated generator, and security behavior, which is mostly authorization checks and belongs alongside functional coverage rather than in a quarterly exercise.
The order worth doing them in
Functional, on the endpoints that matter. Including the negative cases. Everything else is built on this.
Integration, on your real user journeys. Three to five steps each, not twelve.
Authorization checks everywhere. Cheap, and object-level authorization is the most commonly exploited API flaw.
Contract, if services deploy independently. Skip it if you deploy everything together.
Load, before releases. Last, because load testing an incorrect endpoint measures how fast you can be wrong.
The four problems, whichever tool you pick
Four things decide whether an API suite survives its first year: sessions that expire, values that only exist at runtime, calls that depend on each other, and records nobody cleans up. TestSprite handles these as Auto-Authentication, Dynamic Variables, Dependency Chains and Auto-Cleanup, described in the API testing documentation.
Every team meets these in the same order and most meet them by surprise. Designing for them is the difference between a suite that lasts and one that gets quarantined.
The assertion that matters most
Assert on the body, not just the status. A 200 carrying an empty list where a record should be is a bug that a status check calls a pass. This one habit catches more real defects than any other single change.
The first ten cases, concretely
If the suite is empty, the hardest part is deciding where to start, and a generic answer wastes a week. Here is a list that works for most products.
Three for the main object your product is about: create it, fetch it back and assert on the fields, delete it and confirm it is gone. Two for authorization: the same fetch without credentials, and with a second user's credentials. Two for input: a required field missing, and a value out of range. Two for the sequence that makes you nervous before a release, whatever that is for you. One for the endpoint that broke last time.
Ten cases, a morning's work, and they cover the shapes that produce most incidents. Expanding from there should be driven by what actually goes wrong rather than by a coverage target, because the second approach produces suites that are large and beside the point.
Where to start today
Point a project at your service, let discovery enumerate what exists, and read the generated plan before running anything. The plan tells you more about your API than the first results will, and it is where your product knowledge gets added.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
If you would rather not install anything, the dashboard does the same thing. Everything else the command line can do is in the CLI repository.
The GitHub App is a webhook you set up in the TestSprite dashboard. It listens for the deployment event your pipeline already produces, so nothing in your repository changes.
GitHub Actions puts the step inside your own workflow, configured from the terminal.
Where TestSprite sits among the five
Functional, integration and the behavioral half of security. It exercises the running service, generates plans from a discovery pass plus your specification, and covers the negative cases that hand-written suites skip.
Auto-Authentication keeps sessions alive across a run, Dynamic Variables carry values between calls, Dependency Chains derive execution order from what each case needs and produces, and Auto-Cleanup removes exactly what the run created. Those four are what decide whether a suite survives its first year, in any tool, and having them as product is the difference between extending the suite and maintaining it.
Contract testing and load stay separate instruments, and this runs alongside both. What you get is the layer where most user-visible defects live, covered without a framework of your own and running on every pull request.
How much coverage do we need?
Cover the journeys you would be embarrassed to break, plus every endpoint that touches money or permissions. Expand from incidents rather than toward a percentage.
Should we test against production?
Against a representative environment. Creating and deleting records in production to satisfy a test suite carries its own risk.
Do we need a specification?
It helps and is not required. A discovery pass over the running service plus a requirements document gets you a usable plan.
What about mocking?
Mock third parties you do not control. Mocking your own service means testing the mock.
How often should the suite run?
Every pull request for functional and integration, on a schedule for load. A suite that runs weekly finds problems a week late.
Five activities, one order.
API testing means functional, integration, contract, load and security behavior. Do functional and integration first, add authorization checks everywhere, and design for sessions, captured values, ordering and cleanup from the start.