Q30 of 38 · Test design

When should you NOT write a formal test case?

Test designMidtest-designtest-strategycoveragerisk-based-testing

Short answer

Short answer: Skip formal test cases for trivial code already covered by the framework or library (framework internals), one-time throwaway scripts, UI copy changes with no logic, and cases where exploratory testing or static analysis provides better coverage per unit of effort.

Detail

Not every line of code needs a test case. Over-testing has a real cost: test suites that are too large slow the build, produce noise on changes, and make the suite expensive to maintain.

Skip formal test cases when: Framework behaviour is already tested. A getter that delegates entirely to a well-tested ORM does not need a test. You are testing the framework, not your code. The change is purely presentational. A text or colour change with no logic behind it is better caught in a visual regression tool than a scripted test case. The risk is negligible. A utility that formats a debug log entry and is never called in production logic is low enough risk that exploratory testing during code review is sufficient. The cost of the test exceeds the cost of the bug. For a rarely-used admin tool, a one-time fix is cheaper than a maintained test suite.

The decision should be explicit, not accidental. Saying "we consciously decided not to test this because [reason]" is very different from "we forgot."

// WHAT INTERVIEWERS LOOK FOR

Understanding that over-testing has real costs. Ability to make a principled decision about coverage rather than defaulting to 100% or 0%. The distinction between a deliberate gap and negligence.

// Related questions

What is an exploratory test charter and what does one contain?

Test design