Burning Out? Write Ten Smoke Tests Before the Refactor

1. The Burnout Math

Full test coverage is a reasonable goal for a rested team. For a burned out one, it is a trap. You spend three months writing unit tests for code you do not trust, and the code you do not trust is still in production the whole time. The weekend pages keep coming because unit tests do not catch the integration and UI level regressions that wake you up.

A rewrite looks tempting for the same reason a vacation does: it would be nice to start somewhere else. But the production system the rewrite is replacing still needs to run, and you are the one running it. You end up with two full time jobs and no sleep. The smoke test plan, by contrast, attacks the exact source of the 2am page with the smallest surface possible.

2. The Ten Paths, In Priority Order

In order. Do not reorder. If your product lacks one, replace it with your own ninth most painful path.

1. Login, including password reset. If this breaks, everything is down.
2. The one CRUD flow that makes you money. Create, read, update, delete the primary object.
3. Checkout or payment, including the failure branch where the card is declined.
4. Signup, because churn at signup is invisible until you measure it.
5. Role switching or permissions, if your product has tiers or teams.
6. The one admin action you always triple check before running in production.
7. A report or export, because it touches real data at scale and fails silently.
8. The primary inbound webhook, because a silent failure here means lost money.
9. A search or filter page, because these degrade quietly as data grows.
10. Logout that actually clears session state, because auth bugs hide here.

Ten is enough. The instinct to add an eleventh is the same instinct that got you to ninety. Resist it for two weeks.

3. Authoring the Tests

Three options, in rising order of speed and falling order of control.

• Hand write Playwright or Cypress specs. Best control, most maintenance. Budget one to three days per flow.
• Record with Playwright Codegen or Cypress Studio, then clean up the output. Faster, more fragile selectors, still your job to keep green.
• Generate from a natural language scenario with an AI browser agent like Assrt. You describe the flow in plain English, the agent writes the spec, and self-healing behavior keeps selectors stable as the UI drifts.

The reason to care about the maintenance cost is that you are already tired. A recorded suite that green-lights on week one but rots on month three gives back the ground you just won. Pick the option whose maintenance cost you can afford on a bad week, not a good one.

4. Where To Run Them, And When To Page

Two runs, two different rules. PR runs block merges. Synthetic runs page.

PR run:        every PR -> preview deploy -> 10 smoke tests
               fail    -> block merge
               succeed -> allow merge

Synthetic run: every 30 min -> production URL -> 10 smoke tests
               fail    -> page on-call
               succeed -> quiet

The PR rule catches regressions before they reach production. The synthetic rule catches the ones that slip through anyway. Between them, the class of 2am page that is caused by a broken core path goes to zero. You will still get paged for infrastructure issues, but those are different and fewer.

5. The Two-Week Plan

Day by day, roughly.

• Day 1. Pick the ten paths. Write them on paper. Do not touch code yet.
• Day 2-3. Stand up a preview deploy if you do not have one. Vercel, Fly, or Render; whichever is closest.
• Day 4-7. Author the first five tests. Get them green on preview. Merge them behind a feature flag if your CI is strict.
• Day 8-10. Author the second five tests. Same process.
• Day 11-12. Wire the synthetic schedule. Thirty minute interval on production, paging to whatever tool your team uses.
• Day 13-14. Run a deliberate breakage in staging. Confirm the synthetic pages. Tune thresholds.

At the end of two weeks, you have a safety net under the ten flows that used to page you, and you still have not started any refactor. This is the point.

6. What Happens After The Ten Are Green

You sleep. The first weekend without a page is jarring because you keep checking the phone. After the second weekend, the fear of breaking something invisible starts to fade, because the ten most dangerous flows are watched. You get enough headspace back to notice what was actually draining you.

Sometimes that reveals the refactor was the real issue and you still want to do it. Sometimes it reveals the refactor was a symptom of exhaustion and there is a simpler cut that unlocks the same confidence. Either way, you are making the call rested, which was never going to happen under the old rules.

Frequently Asked Questions