Smoke test
A tiny, fast set of checks that the app boots and its core paths work, run before anyone bothers with the slow, deep test suite.
See it
What it is
Named for the hardware ritual of plugging a new board in and seeing whether smoke comes out. A smoke test is a handful of checks that the application is alive and its spine works: the homepage returns 200, the health endpoint answers, a user can log in, the main dashboard renders real data, checkout reaches the payment step. Shallow and wide, deliberately. It is the opposite of a deep test of one feature.
Two moments call for it. Before the long suite runs, so a broken build fails in thirty seconds instead of twenty minutes. And right after a deploy, pointed at the environment you just shipped to, so a bad release gets caught by your script rather than by a customer. In CI this is often the gate between 'deployed' and 'promoted'.
Gotcha: smoke suites gain weight. Someone adds one more edge case, then another, and a year later the fast gate takes eleven minutes and nobody runs it early anymore. Put a hard budget on it (say two minutes), keep it to the flows that would make you roll back, and exile everything else to the full regression suite. Also keep it honest against production: read-only checks, or test accounts and data you are happy to create for real.
Ask AI for it
Write a smoke test suite for this app that finishes in under two minutes. Cover only the spine: health endpoint responds, homepage renders without console errors, login succeeds with a test account, the primary authenticated page loads real data, and one critical action completes. Use Playwright with a configurable BASE_URL so the same suite can run against local, staging, and production. Tag it as 'smoke' so CI can run it as a gate before the full suite and again immediately after deploy.