API test
A test that sends requests directly to an endpoint, then checks the response, errors, and what changed behind the API.
See it
What it is
An API test sends requests straight to an endpoint and checks the HTTP contract and its effects: status, headers, response body, database writes, queued jobs, or the absence of all three after a rejection. It skips the browser and talks in GET, POST, JSON, and status codes. Supertest, Postman, REST Assured, and Playwright's APIRequestContext are common ways to do it.
Reach for API tests when most of the behavior lives behind the route: authentication, validation, pagination, idempotency, or state changes. They run faster and fail more precisely than browser tests, while still covering routing, middleware, serialization, and persistence when wired to real infrastructure.
Gotcha: checking only a 200 status proves very little. Assert the response shape and the side effect, and prove failure paths leave state unchanged. Also isolate each test's data. Two API tests sharing the same account or idempotency key can pass alone and fail in parallel.
Ask AI for it
Write Vitest API tests for POST /orders using Supertest against the running Express app and a real Postgres test database. Cover a valid request, missing authentication, malformed JSON, a validation failure, and reuse of the Idempotency-Key header. Assert status, Content-Type, the JSON response body, and the rows or jobs created. Prove every rejected request leaves the database unchanged, and give each test a unique customer and idempotency key so the suite can run in parallel.