bobmatnyc 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 test-driven-development skill for the complete TDD workflow.
When to Use This Skill
Activate this skill when you're:
- Writing or changing tests - Verify you're testing 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:
□ Am I asserting on mock elements? (testId='*-mock')
→ If yes: STOP - Test real component or unmock
□ Does this method only exist for tests?
→ 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?
→ 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.
If you're testing mock behavior, you've gone wrong. Fix: Test real behavior or question why you're mocking at all.
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
Related Skills
- test-driven-development - Complete TDD workflow (prevents these patterns)
- verification-before-completion - Testing is part of "done"
Key Reminders
- Mocks isolate, don't prove - Test real code, not mocks
- Production ignores tests - No test-only methods
- Understand before mocking - Know dependencies and side effects
- Complete mocks only - Mirror full API structure
- Tests ARE implementation - Not optional afterthought
Red Flags - STOP
STOP immediately if you find yourself:
- Asserting on
*-mocktest IDs - Adding methods only called in test files
- Mocking "just to be safe" without understanding
- Creating mocks from memory instead of API docs
- Saying "tests can wait" or "ready for testing"
When mocks become too complex: Consider integration tests with real components. Often simpler and more valuable.
Integration with Other Skills
Prerequisite: test-driven-development - TDD prevents anti-patterns Complementary: verification-before-completion - Tests = done Domain-specific: webapp-testing, backend-testing for framework patterns