A smoke test after a dependency upgrade is a short, fast check that the upgraded build starts, accepts a request, and completes your few most important user journeys. It does not prove correctness. It answers one question quickly: is this build so broken that nobody should spend more time on it?
What a smoke test is, and is not
A smoke test is a small set of broad checks. Martin Fowler describes a broad-stack test as one that exercises most of the parts of a large application, and notes that such tests are slower and harder to maintain than component tests, which is why a test pyramid suggests fewer of them. That is the right mental model. Keep the smoke set tiny, and let unit and component tests do the detailed work.
A smoke test is not a regression suite, a security scan, or a load test. If it takes more than a few minutes, people start skipping it, and then it stops protecting you.
What to include
Pick checks that fail loudly when a dependency changes underneath you. The upgrade most often breaks things at the seams: startup, configuration, serialization, authentication and the database driver.
| Check | Why an upgrade breaks it |
|---|---|
| Process starts and reports healthy | Changed defaults, removed config keys, import errors |
| Login and one authenticated call | Changed token or cookie handling in a framework or auth library |
| One read and one write against a real database | Driver or ORM behavior changes |
| One call through each outbound integration, against a sandbox | Changed HTTP client, TLS or timeout defaults |
| One background job runs to completion | Queue or scheduler library changes |
| Main page or API route returns the expected shape | Serialization and templating changes |
Add one check for the specific fix. If you upgraded because of an advisory, include a request that would have hit the vulnerable path and confirm it now behaves safely. That turns the smoke test into evidence the patch landed.
What to leave out
Leave out edge cases, long workflows, performance numbers and anything that depends on flaky third parties. Every extra check is another reason for a red build that is not about the upgrade. If a check fails more than once a month for reasons unrelated to code, remove it or fix it.
How to run it
- Build the upgraded version exactly as production builds it, from the lockfile, not from a fresh resolve. For npm,
npm cifails if the lockfile and package.json disagree rather than silently updating the lock, which is the behavior you want in a verification run. - Deploy to a throwaway environment with production-like configuration and fake data.
- Run the smoke set. Cap it at a few minutes.
- If it passes, run the wider suite, then move to a staged rollout. See canary patch rollouts for what to watch after.
- If it fails, stop and bisect the change. Do not widen the rollout to "see if it clears up".
Run the same smoke set again after deployment, against production or the canary, using read-only checks. The set that passed in staging should be the set that confirms the release.
Who owns it
Treat the smoke test as part of the service, kept in the same repository and reviewed like code. When a new critical journey ships, adding it is part of done. When a journey is retired, remove its check.
Safeguard can generate the upgrade pull request and run your policy gates on it, but the smoke set should be yours, because just your team knows which journeys are critical. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look for where a failing check blocks the merge, which is where your smoke job belongs.
Quick check
How long should a smoke test take?
A few minutes at most. If it runs longer, people skip it, so trim it back to startup, authentication, one read, one write and the one check tied to the fix.
Does a passing smoke test mean the upgrade is safe?
No. It means the build is not obviously broken. You still need the normal test suite and a staged rollout with monitoring.
Sources
Last reviewed: 19 October 2026.
