Smoke Testing
debt(d9/e3/b5/t3)
Closest to 'silent in production until users hit it' (d9). The absence of smoke testing is invisible — there is no compiler, linter, or static tool that flags 'you have no post-deploy smoke tests.' The detection_hints confirm no automated post-deploy verification and manual checks skipped under pressure; the gap only surfaces when users hit a broken deployment.
Closest to 'simple parameterised fix' (e3). The quick_fix describes running 5-10 critical path checks post-deploy with tools like playwright, cypress, curl, or github-actions. This is a small, focused addition (a CI pipeline step or script) rather than a one-liner swap, but it doesn't span multiple files or require cross-cutting refactoring.
Closest to 'persistent productivity tax' (b5). Smoke testing applies broadly to web and API contexts, and the common_mistakes note that not automating or not rolling back automatically creates ongoing operational risk. Once adopted, the suite must be maintained alongside every deployment pipeline change, touching devops, CI/CD, and multiple teams' workflows — a persistent but not architectural tax.
Closest to 'minor surprise (one edge case)' (t3). The misconception is specific and bounded: developers conflate smoke tests with integration tests, making them too detailed and slow. This is a documented, common confusion but not a catastrophic or system-wide misunderstanding — a competent developer who reads about smoke testing will quickly learn the 'shallow vs. deep' distinction.
Also Known As
TL;DR
Explanation
Smoke tests answer 'did the deployment break anything obvious?' — they are fast, broad, and shallow. A smoke test suite might check: the home page returns 200, the login endpoint responds, the database is reachable, and a health check passes. If smoke tests fail, the deployment is rolled back immediately without running the full test suite. The name comes from electronics — power on a new circuit and check if it smokes before deeper testing.
Common Misconception
Why It Matters
Common Mistakes
- Smoke tests that are too detailed — they should be fast and broad, not thorough.
- Not automating smoke tests post-deploy — manual checks are skipped under pressure.
- Not rolling back automatically when smoke tests fail — the value is fast automated rollback.
- No smoke tests at all — discovering a broken deployment from user complaints instead of monitoring.
Code Examples
# No post-deploy verification:
deploy_to_production()
# Wait for user complaints or monitoring alerts
# Average time to detect: 5-30 minutes# Automated smoke test in deploy pipeline:
deploy_to_production()
# Run smoke tests immediately:
curl -f https://app.example.com/health || rollback_deploy
curl -f https://app.example.com/api/ping || rollback_deploy
curl -f https://app.example.com/ | grep -q 'Welcome' || rollback_deploy
echo 'Smoke tests passed — deploy confirmed'