API tests

API tests assert HTTP behavior at the boundary: status codes, response schema, validation errors, auth and authorization, pagination, idempotency keys, and correlation IDs in logs. They sit above unit tests but below full browser E2E, often using Supertest, httpx, or REST clients against a running app with test database.

Cover happy path, auth failures, malformed input, and conflict cases—mirror what clients actually send.

On interviews: explain how you test idempotent POST retries and how API tests differ from testing service classes directly.

Common pitfalls: asserting only 200 responses, brittle ordering assumptions, and shared DB state between parallel tests.

The trade-off is faster feedback than UI E2E versus missing client-specific rendering bugs.

Checklist:

• Test auth, validation, and error shapes explicitly.
• Use realistic request bodies and headers.
• Isolate data per test or transaction rollback.