Answer
Yes, cut the tests to the minimum under a tight deadline: keep one test of each main path the new feature adds and every test of code that charges money or checks access, and leave edge cases until after the release.
Verdict on the code under testYes
Why
- Blast radiususers
- Change frequencyregularly
- Detectabilitysame-day
- Reversibilitywith-effort
- Test costmoderate
Cut the tests to the minimum under a tight deadline and keep that minimum: rule R12 gives Test minimally for my typical case, a developer on a product team with a user-facing feature due on a launch date. The deadline changes none of the five factors, because they describe the code and not the calendar. Blast radius is users, since customers meet the broken feature, and Change frequency is regularly, since a feature shipped against a date comes back for fixes in the following sprints. Detectability is same-day, because a broken main path shows up as support tickets on launch day, and Reversibility is with-effort, because records saved by broken code need a repair script. Test cost is moderate, about an hour for an integration test of one path; if the only useful test is heavy, the decision drops to Do not test.
| When | Decision | Why |
|---|---|---|
| The deadline is a trade-show demo, and the demo code is thrown away after the show | Do not test the demo code; click through the demo once before the show | Blast radius falls to none: only the presenter runs the demo |
| The feature due on the deadline charges cards or computes invoices | Test mandatory: test every amount and boundary before the release, and cut other scope if the tests do not fit | Blast radius rises to money and Reversibility to costly: a wrong charge ends in refunds |
| The feature due on the deadline decides which account may read which records | Test mandatory: test allowed, denied and cross-account requests before the release | Blast radius rises to safety-or-legal and Detectability to never: a leaked record raises no error |
| The feature due on the deadline computes values that look plausible when wrong, such as report totals | Test: the main path and the boundary values of the calculation, before the release | Detectability moves to eventually: a wrong total raises no error, and nobody reports it for weeks |
| The deadline is a one-time data migration to a new system | Test it differently: rehearse the migration on a copy of production data, compare counts, and keep a backup | Change frequency falls to once: a test in the suite would never run again |
What breaks if you don't test
Nobody clicks through the feature again after the last change before a deadline. A developer renames a form field in the final hour, the save handler still reads the old name, and new bookings are stored without their time slot. Support hears from customers that afternoon, and the team spends launch week on a hotfix and a script that restores the slots from request logs.
What you lose if you over-test
Edge-case tests for a feature whose details change after the first customer feedback get rewritten within weeks. A coverage target of 80 percent in deadline week pushes a developer to test error branches that few users reach, while the feature itself slips.
How to test
- Keep the existing suite running in CI, and do not mark failing tests as skipped to make the date.
- Write one integration test for each main path the feature adds, such as save and read back, against a real database. The Practical Test Pyramid explains why this level costs less to keep than a browser test.
- Test code that charges money or decides who sees which records at full depth.
- Ship the feature behind a flag, as Feature Toggles describes, so a failure after launch costs a switch instead of a hotfix.
- List the skipped edge cases in a ticket, and add a regression test for each bug users report.
When the answer changes
- The feature charges money, stores personal data, or decides access.
- The deadline is a demo that nobody uses after the day.
- The team requires a test with every change: the framework puts a shared team rule first.
Cost estimate
Two hours before the deadline against six after it
Numbers I assumed for one feature on a web product:
| Item | Assumption | Hours |
|---|---|---|
| Two main-path tests | 1 hour each, the framework's moderate Test cost | 2 |
| One main-path break after launch | Hotfix 3 hours, repair script 2 hours, replies to users 1 hour | 6 |
| Ten edge-case tests | 30 minutes each | 5 |
| One edge-case break after launch | A few users affected, fixed in 1 hour after a report | 1 |
The two main-path tests pay off before launch week ends if the release has a one-in-three chance of a main-path break. The ten edge-case tests pay off only after five edge-case breaks, so they wait until users show which edges fail.
Related questions
FAQ
- Should I write tests when I have a deadline?
Yes, write the minimum set of tests when you have a deadline: one integration test for each main path the feature adds, plus every test of money or access code. By my estimate the minimum takes two hours, and one main-path break costs six hours of hotfix and repair.
- Can I disable failing tests to make a release?
No, a failing test before a release reports a bug in code that users are about to receive, so fix the code before shipping. If the test itself is wrong, fix or delete it with a note in the pull request instead of marking it as skipped.
- What should I test first when time is short?
When time is short, test the code that charges money or decides who may see which records first, then one main path of each new feature. A wrong charge or a leaked record costs refunds or a breach report, which a hotfix does not undo.