Testing Implementation Details

This anti-pattern means writing tests that assert on how code works internally — private methods, internal call sequences, intermediate state — rather than what it does for a caller. The tests become tightly coupled to the current implementation.

Why It Happens

It is tempting to test the easiest reachable surface. When a class exposes internals, or a test framework makes it trivial to spy on every call, developers verify the mechanism instead of the outcome. Heavy use of mocks encourages this: tests end up asserting that method X called method Y in a particular order, which mirrors the code line for line. Sometimes it stems from chasing a coverage number rather than confidence.

Why It Hurts

Tests that mirror implementation break whenever you refactor, even when behavior is unchanged. This penalizes exactly the activity — refactoring — that keeps a codebase healthy, so developers avoid cleanup or rewrite swaths of tests every time. Worse, such tests give false confidence: they confirm the code does what it does, not that it does the right thing, so genuine behavioral bugs can pass. The suite becomes a maintenance tax instead of a safety net.

Warning Signs

• Tests assert on private fields, internal helpers, or exact call order.
• A pure refactor (no behavior change) turns the suite red.
• Mocks are configured to expect a long, specific sequence of internal calls.
• Test code reads like a transcript of the production code.

Better Alternatives

Test through the public interface and assert on observable outcomes: return values, emitted events, persisted state, or messages sent. Treat each unit as a black box — vary inputs, check outputs. Reserve interaction (mock) verification for genuine boundaries you cannot otherwise observe, such as a payment gateway. Behavior-focused and BDD-style tests express intent and survive refactoring because they only care about contract, not construction.

How to Refactor Out of It

Identify tests that break under refactoring and rewrite them to assert outcomes instead of internals. Stop testing private methods directly; if a private method is complex enough to need its own tests, that is a signal to extract it into its own unit with a public contract. Replace strict mock expectations with state verification where possible. When introducing new tests, write them against the interface a real consumer uses. Over time the suite becomes a description of behavior that lets you change internals freely — the whole point of having tests.