essential-test-design

Problem

Tests that are tightly coupled to implementation details cause two failures:

1. False positives — Tests pass even when behavior is broken (e.g., delay shortened but test still passes because it only checks setTimeout was called)
2. False negatives — Tests fail even when behavior is correct (e.g., implementation switches from setTimeout to a delay() utility, spy breaks)

Both undermine the purpose of testing: detecting regressions in behavior.

Principle: Test the Contract, Not the Mechanism

A test is "essential" when it:

• Fails if the behavior degrades (catches real bugs)
• Passes if the behavior is preserved (survives refactoring)
• Does not depend on how the behavior is implemented (implementation-agnostic)

Ask: "What does the caller of this function experience?" — test that.

Anti-Patterns and Corrections