Pre-Deploy Smoke Tests

Quick smoke tests before deploy.

Scope

Smoke tests are the small, fast tests that verify "the basic thing works." Distinct from unit tests (verify code logic) and full integration tests (verify deep behavior), smoke tests verify the essential happy path. They run before deploy to confirm the artifact is launchable; they run after deploy to confirm production is healthy.

What belongs in smoke tests:

• Critical user flows.: The two or three flows that constitute "the product works": login succeeds, the homepage loads, the main API endpoint returns valid data, a sample purchase or write operation completes. These are the flows that, if broken, the product is broken; if working, the product is at least minimally functional.
• Sub-5-minute total.: The whole smoke suite runs in under 5 minutes. Often under 2. The scope is deliberately narrow; the speed is deliberate. A smoke suite that takes 30 minutes is no longer a smoke suite; it is an integration suite that has lost its name.
• Fast confidence signal.: The point of smoke tests is to provide quick confidence that the deploy is not catastrophically broken. They do not provide deep confidence; they provide the floor confidence. Anything that fails smoke is broken in a fundamental way; anything that passes smoke might still have subtle issues.
• Run against real environments.: Smoke tests run against staging or production, not against mocks. They verify the actual deployed system, not a simulated version. This is why they are higher-fidelity than unit tests; they exercise the real network, real dependencies, real configuration.
• Cover the most critical paths.: Pick the 5 or 10 flows that matter most. Resist the temptation to add more; smoke is supposed to be small. Each new test slows the cycle and dilutes the smoke-vs-integration distinction.

Smoke tests are deliberate. The discipline is keeping them focused on essential happy paths rather than letting them grow into another integration suite.

When

Smoke tests run at two specific points in the deploy pipeline: before deploy (against staging or pre-production) and after deploy (against production). Both runs catch different kinds of issues.

• Pre-deploy gate.: Before the artifact ships to production, smoke tests run against staging (or pre-production). The artifact must pass; failure blocks the deploy. This catches the cases where the artifact fundamentally cannot run: missing dependencies, broken database connection, configuration errors that would prevent startup.
• Post-deploy verification.: After the artifact deploys to production, smoke tests run against the production environment. The artifact must pass; failure triggers automatic rollback. This catches the cases where the artifact runs in staging but not in production: production-specific configuration, production-specific data shapes, production-specific dependency states.
• Twice catches issues at both ends.: The two runs catch different classes of issues. Pre-deploy catches "this artifact cannot run." Post-deploy catches "this artifact runs but is not healthy in production." Skipping either run leaves a gap; running both produces continuous confidence.
• Continuous post-deploy monitoring.: Some teams run smoke tests continuously against production, not just immediately after deploy. The continuous run catches degradations that emerge over time (an upstream dependency that drifted, a configuration change that affected behavior). The smoke suite becomes a cheap synthetic monitoring layer.
• Pre-promote canary verification.: In canary deployments, smoke tests run against the canary at each stage before promotion. The canary must pass; failure prevents advancement. The smoke suite gates the rollout step by step.

The two-run pattern is cheap (the same suite runs twice) and high-leverage (catches issues at the two stages where they most commonly emerge).

Avoid

The discipline of smoke tests is keeping them small. The natural drift is to add more tests until smoke becomes integration. The drift defeats the purpose; the discipline resists it.

• Avoid heavy end-to-end tests in smoke.: A user-flow test that exercises 30 screens and verifies dozens of database states is not a smoke test; it is an integration or end-to-end test. It belongs in a separate suite that runs less often. Adding it to smoke makes smoke slow without making it more useful.
• Save deep tests for separate suite.: The deeper integration tests run on a different cadence: nightly, hourly, or after a deploy completes (rather than gating it). They take longer; they verify deeper invariants; they are valuable; they are not smoke.
• Smoke is fast by definition.: The 5-minute ceiling on smoke is the property that defines it. Any test that pushes the total over 5 minutes either gets cut or moves to a different suite. The discipline preserves the property.
• Resist the "while we are at it" instinct.: Engineers naturally want to add coverage for their feature. The instinct is correct; the place is wrong. Smoke is the floor of the testing pyramid; new coverage belongs in unit, integration, or end-to-end suites. The smoke suite stays focused.
• Periodic review and pruning.: Quarterly, review the smoke suite. Are any tests redundant? Has any test gotten slow? Are any tests testing things that no longer matter? The pruning keeps the suite at its design size.

Smoke tests are the small, fast, focused floor of deploy verification. Nova AI Ops integrates with smoke test results across pre-deploy and post-deploy stages, surfaces the cases where smoke has caught (or failed to catch) regressions, and helps the team keep the suite calibrated to its purpose over time.