Smoke testing

A smoke test answers one question quickly: is this build or deployment fundamentally working? For an API that usually means the service starts, health checks pass, authentication works, and a handful of critical endpoints answer with the right status and shape. If smoke fails, there is no point running the full suite.

How it works

Smoke tests run right after a deploy — often against production itself — and before longer suites in CI. They touch every major dependency once (database, cache, auth provider, payment sandbox) with read-only or self-cleaning calls, and they are kept short enough that nobody is tempted to skip them.

The misconception

That a smoke test is a small regression suite. Its job is breadth, not depth: one call through each critical path beats twenty variations of one endpoint. A smoke suite that grows to forty minutes has stopped being a smoke suite.

Try it here

A good first smoke check here: GET /pizza/v1/menu, POST /auth/v1/login, and GET /auth/v1/me with the token it returns — three calls touching public reads, authentication and authorization.

Sources

Other terms

Mock API — A stand-in for a real API that returns realistic responses without the real system behind it.
API sandbox — An isolated copy of an API where calls have no real-world effect and data can be reset.
Mocks, stubs and fakes — Three kinds of test double — stand-ins for a real dependency — that differ in what they do and what they check.
Test fixture — The known data and state a test starts from, set up the same way on every run.
Contract testing — Testing that an API and its consumers agree on the shape of requests and responses, without running them together.
Flaky tests — A test that sometimes passes and sometimes fails without any change to the code it tests.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026