testing anti-patterns

Testing Anti-Patterns Overview Tests must verify real behavior, not mock behavior. Mocks are a means to isolate, not the thing being tested. Core principle: Test what the code does, not what the mocks do. Following strict TDD prevents these anti-patterns. See the Test-Driven Development skill (available in the skill library) for the complete TDD workflow. When to Use This Skill Activate this skill when: Writing or changing tests - Verify tests cover real behavior Adding mocks - Ensure mocking is necessary and correct Reviewing test failures - Check if mock behavior is the issue Tempted to add test-only methods - STOP and reconsider Tests feel overly complex - Sign of over-mocking The Iron Laws 1. NEVER test mock behavior 2. NEVER add test-only methods to production classes 3. NEVER mock without understanding dependencies 4. NEVER create incomplete mocks 5. NEVER treat tests as afterthought Core Anti-Pattern Categories 1. Testing Mock Behavior Asserting on mock elements instead of real behavior. Fix: Test real component or don't mock it. → core-anti-patterns.md 2. Test-Only Methods in Production Methods in production classes only used by tests. Fix: Move to test utilities. → core-anti-patterns.md 3. Mocking Without Understanding Mocking without understanding dependencies/side effects. Fix: Understand first, mock minimally. → core-anti-patterns.md 4. Incomplete Mocks Partial mocks missing fields downstream code needs. Fix: Mirror complete API structure. → completeness-anti-patterns.md 5. Tests as Afterthought Implementation "complete" without tests. Fix: TDD - write test first. → completeness-anti-patterns.md Quick Detection Checklist Run this checklist before committing any test: Language-agnostic checks: □ Am I asserting on mock behavior instead of real behavior? → TypeScript: testId='-mock', expect(mock).toHaveBeenCalled() → Python: mock.assert_called(), mock.call_count → If yes: STOP - Test real behavior or unmock □ Does this method only exist for tests? → TypeScript: destroy(), reset(), clear() only in .test.ts → Python: set_mock, for_testing only in test.py → If yes: STOP - Move to test utilities □ Do I fully understand what I'm mocking? → If no: STOP - Run with real impl first, then mock minimally □ Is my mock missing fields the real API has? → TypeScript: Partial, incomplete objects → Python: Mock() with few attributes, missing nested fields → If yes: STOP - Mirror complete API structure □ Did I write implementation before test? → If yes: STOP - Delete impl, write test first (TDD) □ Is mock setup >50% of test code? → If yes: Consider integration test with real components See: detection-guide.md for comprehensive red flags and warning signs. The Bottom Line Mocks are tools to isolate, not things to test. Testing mock behavior indicates a problem. Fix: Test real behavior or question why mocking is necessary. TDD prevents these patterns. Write test first → Watch fail → Minimal implementation → Pass → Refactor. Navigation Detailed Anti-Pattern Analysis Core Anti-Patterns - Patterns 1-3: Mock behavior, test-only methods, uninformed mocking Completeness Anti-Patterns - Patterns 4-5: Incomplete mocks, tests as afterthought Detection & Prevention Detection Guide - Red flags, warning signs, gate functions TDD Connection - How test-driven development prevents these patterns Language-Specific Examples Python Examples - Complete Python/pytest guide covering all 5 anti-patterns with unittest.mock and pytest-mock patterns, fixture best practices, and pytest-specific detection. Load when working with Python tests.