01
Unit
Business rules, calculations and edge cases — milliseconds per test, no network, no database.
Field note · 2025-04-08
API Testing Strategies
Where API tests belong in your suite, what each layer should cover, and the strategy mistakes that make teams distrust their own pipeline.
Methods and practical guidance from people doing the work.
Direct answer / 01
What is an API testing strategy?
An effective API testing strategy tests each concern at the cheapest layer that can prove it. Unit tests cover business logic; API functional tests cover endpoint behaviour, status codes and error paths; contract tests cover the agreements between services; integration tests cover real interactions with databases and third parties; and a small end-to-end suite covers the handful of journeys that must never break. Layered this way, the majority of coverage runs in seconds on every commit, and only a thin slice depends on slow, brittle full-stack tests.
Layers
Test each concern at the right layer
02
API functional
Request and response behaviour per endpoint: status codes, payload shape, validation and error paths.
03
Contract
Consumer-driven contracts so a provider change cannot silently break a dependent service.
04
Integration
Real database and third-party interactions, including timeout, retry and failure behaviour.
05
End-to-end
A deliberately small set of business-critical journeys exercised through the whole stack.
01 — Question
02 — Evidence
03 — Action
Coverage
What every endpoint suite should include
Happy path plus every documented error response, not just 200 and 500
Input validation: missing fields, wrong types, boundary values, oversized payloads
Authentication and authorisation, including a test that another user's data is inaccessible
Idempotency and duplicate-request behaviour on anything that writes
Pagination, filtering and sorting parameters, including invalid combinations
Schema validation against the OpenAPI specification so drift is caught automatically
Latency assertions so a gradual slowdown fails the build rather than the customer
Mistakes
Where teams waste the most effort
Testing everything end-to-end because the API suite was never built
Shared mutable test data, producing failures that depend on execution order
Mocking your own services so thoroughly that no test proves they actually integrate
Skipping contract tests, then discovering the breakage in production
Asserting on entire response bodies, so every harmless field addition fails the suite
Retrying flaky tests until green instead of fixing the cause
CI
Making the strategy stick in your pipeline
Run unit and API functional tests on every commit, contract tests on every service build, integration on merge, and the small end-to-end suite on release candidates. Anything slower than ten minutes at the commit stage will be routed around by your developers, eventually.
Publish the results where people read them, quarantine flaky tests rather than retrying them, and treat a red pipeline as a stop condition. A suite that is sometimes wrong is worse than no suite, because it teaches the team to ignore failures.
Useful answers
Questions,
clarified.
Functional behaviour of every endpoint, input validation, authentication and authorisation, contracts between services, integration with real dependencies, performance baselines and schema conformance — each tested at the cheapest layer that can prove it.
Contract testing verifies that the agreement between a service and its consumers holds. Consumers declare what they need; the provider's build fails if it stops meeting that expectation — catching breakages before deployment rather than after.
As many as can finish in a few minutes. API tests are fast, so most teams can run their entire functional suite per commit, reserving integration and end-to-end tests for later pipeline stages.
Mock them in fast functional tests for determinism, but keep a small set of contract or sandbox tests that exercise the real integration. Otherwise you're testing your mocks, not the provider.
Postman and Newman for approachable suites, REST Assured for JVM teams, Playwright's request API when you're already using Playwright, Pact for contracts, and k6 for endpoint performance.
Authorisation tests proving one user cannot access another's data, input validation and injection attempts, rate-limit behaviour, token expiry and refresh handling, and OWASP API Security Top 10 coverage.
Next signal
Turn uncertainty into a clear plan.
Tell us what you are building and where quality or design is slowing you down.
Start a conversation