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 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

1. Mocks isolate, don't prove - Test real code, not mocks
2. Production ignores tests - No test-only methods
3. Understand before mocking - Know dependencies and side effects
4. Complete mocks only - Mirror full API structure
5. Tests ARE implementation - Not optional afterthought

Red Flags - STOP

STOP immediately if you find yourself:

• Asserting on *-mock test 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