This is the minimum kit for testing an HTTP API properly: a spec, a client, a mock, a fuzzer, a load tool and a CI wire-up. Six pieces, all free, all runnable from a terminal.
Write an OpenAPI 3.1 document before you write tests, because half the tooling below reads it. 3.1 is the version that aligns with JSON Schema proper, so your request and response schemas are reusable outside the API layer. Keep it in the repo next to the code and validate it in CI with redocly lint openapi.yaml — a spec that drifts is worse than no spec.
Hurl is the lightest option: plain text, one file per feature, assertions inline.
GET http://localhost:8080/users/1
HTTP 200
[Asserts]
jsonpath "$.email" contains "@"
header "Content-Type" == "application/json"
Run the lot with hurl --test --variable host=localhost:8080 tests/. If your team prefers a GUI, Bruno stores collections as files you can diff and review, which Postman's cloud workspaces do not.
prism mock openapi.yaml serves a mock API straight from the spec, complete with example responses and validation of incoming requests. This kills the most common integration delay — the client team waiting on the server team — and it fails loudly the moment the spec and the client disagree.
schemathesis run --checks all http://localhost:8080/openapi.json generates requests that satisfy and violate your schema and reports every response that does not match what you documented. In practice the first run on a mature API finds unhandled 500s on null values, integer overflow in pagination parameters, and endpoints returning 200 with an error body.
k6 scripts are JavaScript, so you can reuse request-building code. A useful first script ramps to 50 virtual users over a minute and asserts a threshold: thresholds: { http_req_duration: ['p(95)<500'] }. Run it against a staging environment sized like production, not against your laptop, or the numbers mean nothing.
This is the part that decides whether the suite survives. Bring up dependencies per run with docker compose up -d or Testcontainers, apply migrations, and seed a fixed dataset. Every test either creates what it needs or asserts against seeded IDs — never against "whatever is in the database". Wrap it so a single command, make test, does all of it on a clean machine.
Order matters: lint the spec, start the service, run Hurl, then Schemathesis, then k6 as a separate non-blocking job. Fail the build on the first three. Keep the whole blocking path under five minutes — beyond that people start pushing with the suite disabled, and the starter pack becomes shelfware.