Smoke Tests
Smoke tests are a fast, shallow set of checks confirming a build or deployment is basically usable before deeper testing or real traffic begins.
Definition
Smoke testing verifies that the most critical paths of a build start and respond correctly, providing a quick go or no-go signal.
Context and scope
Run after deployments, container starts, and configuration changes, and as the first stage of a broader test pipeline.
Common misconceptions
- Smoke tests are a small end-to-end suite that proves the release works
- Smoke testing and sanity testing are the same practice
- A green smoke run means no further testing is needed
Anti-patterns
- Letting the smoke suite grow until it takes an hour
- Checking only that a process starts while ignoring its dependencies
- Skipping smoke tests because staging passed earlier
Related concepts
Related examples
Authoritative source
The go or no-go check
Smoke tests answer a blunt question: is this build alive enough to test further? They log in, load the home page, call a health endpoint, and maybe submit one harmless write. They run in minutes, often seconds. The name comes from hardware, where powering on a board and watching for smoke reveals catastrophic faults before detailed diagnosis. Software smoke tests serve the same purpose: catch a broken deployment before it reaches users or consumes a long test cycle.
Smoke versus sanity
The terms are often conflated. Smoke testing is broad and shallow, checking that major functions start at all. Sanity testing is narrow and deeper, confirming that a specific fix or change behaves correctly. A deployment gate usually needs smoke tests; a bug fix needs a sanity check. Both are subsets of regression testing, but they answer different questions.
As a deployment gate
Modern delivery pipelines run smoke tests immediately after a rollout, before shifting traffic. If the check fails, the pipeline stops or rolls back automatically. This is especially valuable with progressive delivery, where a canary receives a small slice of traffic first. The smoke test should exercise the deployed artifact, not a locally built copy, and should verify dependencies such as databases, caches, and queues.
Designing a good suite
Keep it small and stable. Choose paths whose failure makes the release pointless: authentication, the primary read path, and the primary write path. Assert on meaningful responses, not only HTTP 200. Make the suite independent of test data that changes daily. For example, checking out a real product is a poor smoke test; reading a fixed catalog entry is better.
Limits
Smoke tests cannot prove correctness, performance, or security. They intentionally ignore most of the product. Their value depends on staying fast and trusted, so resist the pressure to add every new feature to them.