Testing Anti-Patterns

Overview

Tests must validate real behavior, not mock behavior. Mocks are isolation tools; they are never the subject under test. Follow these guardrails whenever you touch tests or mocks.

Iron Laws

1. NEVER test mock behavior
2. NEVER add test-only methods to production classes
3. NEVER mock without understanding dependencies
4. NEVER ship incomplete mocks
5. NEVER treat integration tests as an afterthought

Anti-Pattern 1: Testing Mock Behavior

• ❌ Example: asserting getByTestId('sidebar-mock') exists after mocking <Sidebar/>.
• Why wrong: proves mock works, says nothing about component.
• ✅ Fix: test the real component (or mock only for isolation but assert behavior, not mock internals).

Gate: Before asserting on a mock, ask “Am I testing actual behavior or just the mock?” If it’s the mock, delete the assertion or unmock.

Anti-Pattern 2: Test-Only Methods in Production

• ❌ Example: adding Session.destroy() only used in tests.
• Why wrong: pollutes prod API, dangerous if called live.
• ✅ Fix: move cleanup helpers to test utils; production classes expose only real lifecycle.

Gate: Before adding a method, ask “Is this only for tests?” and “Does this class own the lifecycle?” If “yes” or “no” respectively, stop.

Anti-Pattern 3: Mocking Without Understanding

• ❌ Mocking a high-level method that also writes config, causing duplicate detection to fail.
• ✅ Mock only the slow/external portion (e.g., server startup) so necessary side effects remain.

Gate: Before mocking, answer:

1. What side effects does the real method have?
2. Does the test rely on them?
3. Do I fully understand the dependency chain? If unsure, run with real implementation first, observe, then mock minimally.

Anti-Pattern 4: Incomplete Mocks

• ❌ Mock response with only fields you use; downstream needs metadata.requestId.
• ✅ Mirror the full real schema (status, data, metadata, etc.).

Gate: Examine real API/docs, include every field consumers might touch. If uncertain, copy the full structure.

Anti-Pattern 5: Integration Tests as Afterthought

• ❌ Implementation “done” without tests.
• ✅ Follow TDD: write failing test, implement, refactor.

Over-Complex Mocks

If mock setup eclipses test logic, reconsider. Ask “Do we need a mock here?” Integration tests with real components may be simpler.

TDD Prevents These

Following TDD ensures tests verify real behavior (fail first), prevents test-only prod code, and reveals when mocks are unnecessary.

Quick Reference

Red Flags

• Assertions referencing *-mock
• Methods only invoked from tests
• Mock setup >50% of test
• Tests fail when mock removed
• “Mocking to be safe” rationale

Bottom line: Mocks isolate but are never the unit under test. Test real behavior, and let TDD guide your workflow.