What is Smoke Testing?

Smoke testing is a fast, lightweight set of tests run against a new build or deployment to verify that the most critical functionality is working and the build is stable enough to proceed with more thorough testing. The name comes from electronics: power on a new circuit board and check if smoke appears before investing more time in detailed testing.

Purpose of Smoke Testing

Smoke tests are not designed to be comprehensive. They are designed to be fast and catch catastrophic failures — the application does not start, the database connection fails, the login page returns a 500 error — that would make deeper testing impossible or wasteful. If smoke tests fail, the build is rejected immediately, saving the time that a full regression suite would take.

What Smoke Tests Cover

• Application starts without errors
• Critical pages return expected status codes
• Authentication and authorization basic flows work
• Database connectivity and critical queries execute
• Key API endpoints respond within expected time
• Third-party integrations respond or fail gracefully

Smoke Testing in the Deployment Pipeline

Smoke tests run after deployment to production are called sanity tests or post-deployment verification. They confirm the deployment itself succeeded, not just that the code is correct.

Smoke Testing vs Sanity Testing

These terms are often used interchangeably but have a common distinction: smoke testing validates that a new build is worth testing further. Sanity testing validates a specific area of functionality after a targeted change, verifying that the fix worked without running the full regression suite.

Designing Good Smoke Tests

• Keep them fast — smoke tests should complete in under 5 minutes
• Cover critical user journeys, not every feature
• Make them reliable — a flaky smoke test defeats the purpose
• Run them at every stage of the pipeline where a deployment occurs
• Include basic infrastructure checks alongside application checks

Smoke Testing and Autonomous Code Governance

Hydra uses smoke test results as an immediate signal after automated changes are deployed. When Hydra generates a dependency update or security patch, smoke tests provide fast confirmation that the application is still functional before the full regression suite runs. Failed smoke tests trigger immediate notification and potential automated rollback.

Frequently Asked Questions

Are smoke tests a replacement for regression tests?

No. Smoke tests confirm the build is stable enough to test. Regression tests confirm that all existing functionality is preserved. Both are necessary, running at different points in the pipeline.

How many tests should be in a smoke suite?

As few as needed to provide confidence that the application is functional. Typically 10-50 tests covering the most critical user-facing paths. The constraint is speed: if smoke tests take more than 5-10 minutes, they lose their value as a quick gate.

Should smoke tests run in production?

Yes. Post-deployment smoke tests in production confirm that the deployment succeeded and the application is serving traffic correctly. They should be non-destructive read-only operations or use dedicated test accounts.

What happens when a smoke test fails in production?

A failed post-deployment smoke test should trigger an immediate rollback in a system practicing continuous deployment or alert the on-call engineer for evaluation. The failed smoke test becomes the diagnostic starting point.