discriminating-testing
Discriminating Testing
Optimize for tests that catch plausible bugs, not for test count, framework usage or ritual compliance.
Core rule
For each test of semantic correctness, be able to answer:
- What plausible mistake or alternative interpretation does this target?
- Would this exact input make the correct and wrong implementations behave differently?
- If it asserts an expected value, is that value derived independently of the implementation under test?
If a semantic assertion cannot distinguish the intended behavior from the targeted mistake, redesign it or remove the redundant assertion. Smoke, compile/link, crash, deadlock, race, and resource-leak checks have their own observable contracts; retain useful checks without pretending they prove expected-value semantics.
Scope and effort
Scope verification to the requested behavior and semantics affected by the change. Broaden only when evidence reveals a concrete related risk or the user requests a wider audit. A mechanical rename or reversible low-impact edit does not require new tests solely because it touches complex code. Reuse an existing test when it already distinguishes the relevant plausible failure.