API Testing Strategy
Why test APIs separately
- Faster than UI test.
- More stable.
- Cover scenario hard from UI (rate limit, malformed request).
- Contract for mobile + web client.
Test pyramid for API
- Unit — function in handler.
- Component — single endpoint.
- Integration — multi-endpoint flow.
- Contract — consumer-driven (Pact).
- End-to-end — through real service.
Tools comparison
| Tool | Type | Best for |
|---|
| Postman + Newman | GUI + CLI | Manual + simple CI |
| REST Assured | Java DSL | JVM team |
| Supertest | Node.js | JS team |
| Karate | DSL | BDD style |
| Pact | Contract | Microservice |
| K6 | JS code | Performance + functional |
Test categories
- Status code — 200, 201, 400, 401, 404, 500.
- Response schema — match contract.
- Response time — p95 < SLA.
- Auth — token required, valid.
- Permission — role-based access.
- Rate limit — throttle enforced.
- Idempotency — same request twice = same result.
- Pagination — cursor work correctly.
- Validation — bad input → 400 with message.
Schema validation
- OpenAPI / Swagger spec → test verify response match.
- Tools: Dredd, Schemathesis.
Contract testing
Consumer (mobile) define expectations → Provider (backend) verify never break.
- Pact Broker host contracts.
- Backend CI run "verify contracts" gate.
Security in API test
- Test authn (login flow).
- Test authz (user A can't access user B's data).
- Test SQL injection —
'; DROP TABLE users;--.
- Test XSS in stored response.
- Test JWT manipulation.
VN context
Microservice phổ biến Tiki, Shopee, MoMo — contract test essential.