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<T>, 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](references/core-anti-patterns.md) - Patterns 1-3: Mock behavior, test-only methods, uninformed mocking
• [Completeness Anti-Patterns](references/completeness-anti-patterns.md) - Patterns 4-5: Incomplete mocks, tests as afterthought

Detection & Prevention

• [Detection Guide](references/detection-guide.md) - Red flags, warning signs, gate functions
• [TDD Connection](references/tdd-connection.md) - How test-driven development prevents these patterns

Language-Specific Examples

• [Python Examples](references/python-examples.md) - 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.

Related Skills

When using this skill, consider these complementary skills (if deployed in your skill bundle):

• test-driven-development: Complete TDD workflow and red-green-refactor cycle
• Use case: Implementing TDD discipline to prevent anti-patterns
• Integration: TDD workflow prevents most anti-patterns by design
• Status: Recommended - basic anti-patterns covered in this skill

• verification-before-completion: Definition of "done" and verification protocols
• Use case: Ensuring tests are part of completion criteria
• Integration: Tests must pass before work is considered complete
• Status: Recommended - testing mindset reinforcement

Note: All skills are independently deployable. This skill is fully functional without them.

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

• Testing mock behavior
• TypeScript: Asserting on *-mock test IDs, expect(mock).toHaveBeenCalled()
• Python: mock.assert_called(), mock.call_count without real behavior checks
• Adding test-only methods
• TypeScript: destroy(), reset() only in *.test.ts
• Python: _set_mock_*, _for_testing with "For testing only" docstrings
• Mocking without understanding
• Adding @patch or vi.mock() "just to be safe"
• Creating mocks from memory instead of API docs
• Incomplete mocks
• TypeScript: Partial<T>, missing nested objects
• Python: Mock() for data objects, missing required fields
• Tests as afterthought
• Saying "tests can wait" or "ready for testing"
• Implementation commits before test commits

When mocks become too complex: Consider integration tests with real components. Often simpler and more valuable.

Integration with Other Skills

Prerequisite: Test-Driven Development skill - TDD prevents anti-patterns (recommended for complete workflow) Complementary: Verification-Before-Completion skill - Tests = done (ensures proper testing discipline) Domain-specific: webapp-testing, backend-testing for framework patterns (see skill library if available)

Completeness Anti-Patterns

Anti-patterns related to incomplete testing practices: partial mocks that hide structural dependencies, and treating tests as optional afterthoughts instead of integral parts of implementation.

Anti-Pattern 4: Incomplete Mocks

The Violation

[TypeScript/Jest]

// ❌ BAD: Partial mock - only fields you think you need
const mockResponse = {
  status: 'success',
  data: { userId: '123', name: 'Alice' }
  // Missing: metadata that downstream code uses
};

// Later: breaks when code accesses response.metadata.requestId

[Python/pytest]

# ❌ BAD: Incomplete mock missing fields
from unittest.mock import Mock

def test_display_user_profile():
    mock_user = Mock()
    mock_user.id = 123
    mock_user.name = "Alice"
    # Missing: email, profile, metadata

    result = display_user_profile(mock_user)

    # Test passes but production code may access user.profile.timezone
    # → AttributeError in production!

Why this is wrong:

• Partial mocks hide structural assumptions - You only mocked fields you know about
• Downstream code may depend on fields you didn't include - Silent failures
• Tests pass but integration fails - Mock incomplete, real API complete
• False confidence - Test proves nothing about real behavior
• Breaking changes go undetected - API changes don't fail tests

The Iron Rule: Mock the COMPLETE data structure as it exists in reality, not just fields your immediate test uses.

Real-world impact:

[TypeScript/Jest]

// Your test (incomplete mock)
const mockUser = { id: '123', name: 'Alice' };
// Passes ✅

// Production code elsewhere
function getUserTimezone(user) {
  return user.profile.timezone;  // undefined - breaks in production!
}

[Python/pytest]

# Your test (incomplete mock)
mock_user = Mock(id=123, name="Alice")
# Passes ✅

# Production code elsewhere
def get_user_timezone(user):
    return user.profile.timezone  # AttributeError in production!

Complete Mock Strategy

The fix:

[TypeScript/Jest]

// ✅ GOOD: Mirror real API completeness
const mockResponse = {
  status: 'success',
  data: {
    userId: '123',
    name: 'Alice',
    email: 'alice@example.com',
    profile: {
      timezone: 'America/New_York',
      locale: 'en-US',
      avatar: 'https://...'
    }
  },
  metadata: {
    requestId: 'req-789',
    timestamp: 1234567890,
    version: 'v2'
  }
  // All fields real API returns
};

[Python/pytest]

# ✅ GOOD: Complete mock or use fixture
from dataclasses import dataclass
from typing import Optional

@dataclass
class User:
    id: int
    name: str
    email: str
    profile: 'UserProfile'
    metadata: dict

@dataclass
class UserProfile:
    timezone: str
    locale: str
    avatar: Optional[str]

# Fixture factory
def create_test_user(**overrides) -> User:
    """Complete user with all required fields"""
    defaults = {
        "id": 123,
        "name": "Alice",
        "email": "alice@example.com",
        "profile": UserProfile(
            timezone="UTC",
            locale="en-US",
            avatar=None
        ),
        "metadata": {}
    }
    return User(**{**defaults, **overrides})

def test_display_user_profile():
    user = create_test_user(name="Alice")

    result = display_user_profile(user)

    assert "Alice" in result
    assert "UTC" in result

How to Create Complete Mocks

Step 1: Reference real API documentation

// ❌ BAD - mocking from memory
const mock = { id: 1, name: 'test' };

// ✅ GOOD - reference API docs
// From API docs: GET /api/users/:id returns:
// {
//   id: number,
//   name: string,
//   email: string,
//   createdAt: ISO8601,
//   profile: { ... },
//   permissions: string[]
// }

const mock = {
  id: 1,
  name: 'test',
  email: 'test@example.com',
  createdAt: '2024-01-01T00:00:00Z',
  profile: { /* complete profile */ },
  permissions: ['read', 'write']
};

Step 2: Use TypeScript types

// ✅ TypeScript ensures completeness
interface User {
  id: string;
  name: string;
  email: string;
  profile: UserProfile;
  metadata: UserMetadata;
}

// TypeScript error if incomplete
const mockUser: User = {
  id: '123',
  name: 'Alice'
  // Error: Missing email, profile, metadata
};

// Must be complete
const mockUser: User = {
  id: '123',
  name: 'Alice',
  email: 'alice@example.com',
  profile: { timezone: 'UTC', locale: 'en' },
  metadata: { createdAt: '2024-01-01T00:00:00Z' }
};

Step 3: Extract mock factories

// ✅ Reusable complete mocks
// test-utils/factories/user.ts
export function createMockUser(overrides?: Partial<User>): User {
  return {
    id: '123',
    name: 'Test User',
    email: 'test@example.com',
    profile: {
      timezone: 'UTC',
      locale: 'en-US',
      avatar: null
    },
    metadata: {
      createdAt: '2024-01-01T00:00:00Z',
      updatedAt: '2024-01-01T00:00:00Z',
      version: 1
    },
    permissions: ['read'],
    ...overrides  // Allow customization
  };
}

// Usage
const user = createMockUser({ name: 'Alice' });
// All fields present, name overridden

Detecting Incomplete Mocks

Red flags:

• Creating mocks without referencing API docs
• TypeScript any or Partial<T> for mocks
• Different tests have different mock shapes for same type
• Mock has fewer fields than real API
• Comments like "add fields as needed"

Gate Function:

BEFORE creating mock responses:
  Check: "What fields does the real API response contain?"

  Actions:
    1. Open API documentation or OpenAPI spec
    2. List ALL fields in response
    3. Include ALL fields in mock (use TypeScript types)
    4. Verify mock matches real response schema completely

  Critical:
    If you're creating a mock, you must understand the ENTIRE structure
    Partial mocks fail silently when code depends on omitted fields

  If uncertain:
    - Include all documented fields
    - Use TypeScript interfaces to enforce completeness
    - Create factory functions for reusable complete mocks

  Red flags:
    - "I'll add more fields later"
    - "Just mocking what I need"
    - Creating mock from memory
    - Different mock shapes for same entity

Common Incomplete Mock Scenarios

Scenario 1: Nested objects

// ❌ BAD - incomplete nesting
const mockUser = {
  id: '123',
  profile: { name: 'Alice' }  // Missing profile.timezone, profile.locale
};

// ✅ GOOD - complete nesting
const mockUser = {
  id: '123',
  profile: {
    name: 'Alice',
    timezone: 'UTC',
    locale: 'en-US',
    avatar: null,
    bio: null
  }
};

Scenario 2: Arrays

// ❌ BAD - empty array when real data has items
const mockResponse = {
  users: []  // Real API always has pagination metadata
};

// ✅ GOOD - realistic array with metadata
const mockResponse = {
  users: [
    { id: '1', name: 'Alice', /* complete user */ },
    { id: '2', name: 'Bob', /* complete user */ }
  ],
  pagination: {
    total: 2,
    page: 1,
    perPage: 10,
    hasNext: false
  }
};

Scenario 3: Optional fields

// ❌ BAD - omitting optional fields
const mockUser = {
  id: '123',
  name: 'Alice'
  // Omitted optional fields - downstream code may check them
};

// ✅ GOOD - include optional fields (as null/undefined)
const mockUser = {
  id: '123',
  name: 'Alice',
  bio: null,           // Optional field explicitly null
  website: undefined,  // Optional field explicitly undefined
  avatar: null
};

Mock Completeness Levels

Level 1: Minimal (AVOID)

// Only immediate test needs
const mock = { id: '123' };
// Risk: High - downstream code breaks

Level 2: Partial (RISKY)

// Common fields included
const mock = { id: '123', name: 'Alice', email: 'alice@example.com' };
// Risk: Medium - missing nested/optional fields

Level 3: Complete (REQUIRED)

// All fields from API spec
const mock = {
  id: '123',
  name: 'Alice',
  email: 'alice@example.com',
  profile: { /* complete */ },
  metadata: { /* complete */ },
  permissions: ['read']
};
// Risk: Low - matches real API

Level 4: Factory-based (BEST)

// Reusable factory with defaults
const mock = createMockUser({ name: 'Alice' });
// Risk: Minimal - centralized, typed, complete

Anti-Pattern 5: Tests as Afterthought

The Violation

[TypeScript/Jest]

// ❌ BAD - Implementation before tests
// 1. Wrote UserService class
// 2. Wrote createUser() method
// 3. Wrote updateUser() method
// 4. Now writing tests to achieve coverage

test('creates user', () => {
  // Test confirms what code DOES, not what it SHOULD do
  // Bugs baked into test expectations
});

[Python/pytest]

# ❌ BAD - Implementation before tests
# 1. Wrote create_user() function
# 2. Wrote update_user() function
# 3. Wrote delete_user() function
# 4. Now writing tests to achieve coverage

def test_create_user():
    # Test confirms what code DOES, not what it SHOULD do
    # Bugs baked into test expectations
    pass

Why this is wrong:

• Testing is part of implementation, not optional follow-up
• TDD would have caught this
• Can't claim complete without tests
• Tests written after code are biased toward existing implementation
• Missing tests = incomplete feature
• Technical debt from day one

The Fix - TDD

[TypeScript/Jest]

// ✅ GOOD - Test first (TDD)

// Step 1: RED - Write failing test
test('creates user with valid email', () => {
  const service = new UserService();
  expect(() => service.createUser('invalid-email')).toThrow('Invalid email');
  // ❌ Test fails - createUser doesn't exist
});

// Step 2: GREEN - Minimal implementation
class UserService {
  createUser(email: string): User {
    if (!email.includes('@')) throw new Error('Invalid email');
    return new User(email);
  }
}
// ✅ Test passes

// Step 3: REFACTOR - Improve without breaking test
class UserService {
  createUser(email: string): User {
    this.validateEmail(email);  // Extracted validation
    return new User(email);
  }
  // ✅ Test still passes
}

[Python/pytest]

# ✅ GOOD - Test first (TDD)

# Step 1: RED - Write failing test
def test_create_user_validates_email():
    with pytest.raises(ValidationError):
        create_user("invalid-email")
    # ❌ Test fails - create_user doesn't exist

# Step 2: GREEN - Minimal implementation
def create_user(email: str) -> User:
    if "@" not in email:
        raise ValidationError("Invalid email")
    return User(email=email)
    # ✅ Test passes

# Step 3: REFACTOR - Improve without breaking test
def create_user(email: str) -> User:
    validate_email(email)  # Extracted validation
    return User(email=email)
    # ✅ Test still passes

Why Tests Must Come First

Tests-after problems:

1. Implementation bias

• Tests confirm what code does, not what it should do
• Bugs baked into tests
• Missing edge cases

2. Design issues

• Code hard to test (not designed for testability)
• Tight coupling discovered too late
• Refactoring required to make testable

3. Coverage gaps

• Temptation to skip "hard to test" paths
• Error handling overlooked
• Edge cases ignored

4. False completion

• Feature seems done but untested
• Integration issues discovered late
• Delayed feedback loop

Tests-first benefits:

1. Design driver

• Forces testable design upfront
• Identifies coupling before writing code
• API designed from consumer perspective

2. Verification

• Confirms implementation matches requirements
• Catches bugs immediately
• Documents expected behavior

3. Confidence

• Safe refactoring
• Regression prevention
• Living documentation

Integration Testing Strategy

When to write integration tests:

• Before implementation (TDD approach)

  // 1. Write failing integration test
  test('user registration flow', async () => {
    const response = await api.post('/register', userData);
    expect(response.status).toBe(201);
    expect(response.body.user).toMatchObject(userData);
  });
  // Test fails - endpoint doesn't exist

  // 2. Implement endpoint
  // 3. Test passes

• Alongside unit tests (test pyramid)
• Unit tests: Fast, isolated, many
• Integration tests: Realistic, end-to-end, fewer
• Both written before/during implementation

Types of integration tests:

1. API integration tests

   test('POST /api/users creates user', async () => {
     const response = await request(app)
       .post('/api/users')
       .send({ name: 'Alice', email: 'alice@example.com' });

     expect(response.status).toBe(201);
     expect(response.body).toMatchObject({
       id: expect.any(String),
       name: 'Alice',
       email: 'alice@example.com'
     });

     // Verify database
     const user = await db.users.findById(response.body.id);
     expect(user).toBeDefined();
   });

2. Database integration tests

   test('user repository saves and retrieves users', async () => {
     const user = await userRepo.create({
       name: 'Alice',
       email: 'alice@example.com'
     });

     const retrieved = await userRepo.findById(user.id);
     expect(retrieved).toEqual(user);
   });

3. Component integration tests

   test('UserForm submits to API', async () => {
     render(<UserForm />);

     fireEvent.change(screen.getByLabelText('Name'), {
       target: { value: 'Alice' }
     });
     fireEvent.click(screen.getByText('Submit'));

     await waitFor(() => {
       expect(mockApi.post).toHaveBeenCalledWith('/users', {
         name: 'Alice'
       });
     });
   });

Test Completeness Checklist

Before claiming implementation complete:

□ Unit tests written and passing
  - All public functions tested
  - Edge cases covered
  - Error conditions tested

□ Integration tests written and passing
  - End-to-end flows tested
  - External dependencies tested
  - Error handling tested

□ Test coverage meets threshold (e.g., 80%)
  - Line coverage
  - Branch coverage
  - Critical paths covered

□ Tests run in CI/CD pipeline
  - Automated on commits
  - Blocks merge if failing

□ Tests document behavior
  - Clear test names
  - Meaningful assertions
  - Edge cases explained

Gate Function

BEFORE claiming implementation complete:
  Ask: "Are tests written?"

  IF no:
    STOP - Not complete
    Write tests before continuing

  Ask: "Do tests cover all requirements?"

  IF no:
    STOP - Incomplete testing
    Add missing test cases

  Ask: "Did I follow TDD (test-first)?"

  IF no:
    WARNING - Consider rewriting with TDD
    Tests may be implementation-biased

  Ask: "Do integration tests pass?"

  IF no:
    STOP - Not ready for integration
    Fix integration issues

  Definition of "complete":
    ✅ Unit tests written and passing
    ✅ Integration tests written and passing
    ✅ Coverage meets threshold
    ✅ Tests run in CI/CD
    ✅ All requirements verified

Recovery: Adding Tests After Implementation

If tests weren't written first (damage control):

1. Stop adding features - Don't dig deeper hole 2. Write tests for existing code - Start with critical paths 3. Refactor for testability - Decouple as needed 4. Adopt TDD going forward - Prevent future occurrence

Prioritization:

• High priority: Critical business logic, security, data integrity
• Medium priority: Common user flows, API endpoints
• Low priority: UI styling, configuration, one-off scripts

Approach:

// 1. Write characterization tests (document current behavior)
test('current behavior: user registration', async () => {
  const result = await registerUser(userData);
  // Document what currently happens
  expect(result).toMatchSnapshot();
});

// 2. Add specific behavior tests
test('user registration validates email', async () => {
  await expect(registerUser({ email: 'invalid' }))
    .rejects.toThrow('Invalid email');
});

// 3. Refactor safely with test coverage
// Now can refactor with confidence

Prevention Through TDD

How TDD prevents completeness anti-patterns:

1. Incomplete mocks

• Writing test first forces understanding of data structures
• Failing test shows what fields are needed
• Implementation reveals missing mock fields immediately

2. Tests as afterthought

• TDD makes tests part of implementation process
• Can't write implementation without test
• Test-first is the workflow, not optional step

TDD workflow enforces:

• Complete understanding of requirements (to write test)
• Complete data structures (test fails if incomplete)
• Complete coverage (tests drive implementation)

See the Test-Driven Development skill for complete TDD workflow (available in the skill library for comprehensive TDD guidance).

Real-World Impact

Incomplete mocks:

• Tests pass, production breaks
• Integration issues discovered late
• False confidence in test suite
• Difficult debugging (mock ≠ reality)

Tests as afterthought:

• Bugs escape to production
• Implementation hard to test (design issues)
• Coverage gaps
• Technical debt from day one

With complete approach:

• Tests catch integration issues early
• High confidence in test suite
• Testable design from start
• Complete feature = tested feature

Core Testing Anti-Patterns

The three most critical testing anti-patterns that violate fundamental testing principles. These patterns test mock behavior instead of real behavior, pollute production code with test concerns, or mock without understanding dependencies.

Anti-Pattern 1: Testing Mock Behavior

The Violation

[TypeScript/Jest]

// ❌ BAD: Testing that the mock exists
test('renders sidebar', () => {
  render(<Page />);
  expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();
});

[Python/pytest]

# ❌ BAD: Testing mock behavior, not real code
from unittest.mock import Mock

def test_send_email():
    mock_mailer = Mock()

    send_welcome_email(mock_mailer, "user@example.com")

    # Asserting on MOCK behavior
    assert mock_mailer.send_email.called  # Testing the mock!
    assert mock_mailer.send_email.call_count == 1
    mock_mailer.send_email.assert_called_with("user@example.com", "Welcome!")

Why this is wrong:

• You're verifying the mock works, not that the component/function works
• Test passes when mock is present, fails when it's not
• Tells you nothing about real behavior
• False confidence - production may still be broken

your human partner's correction: "Are we testing the behavior of a mock?"

The Fix

[TypeScript/Jest]

// ✅ GOOD: Test real component or don't mock it
test('renders sidebar', () => {
  render(<Page />);  // Don't mock sidebar
  expect(screen.getByRole('navigation')).toBeInTheDocument();
});

// OR if sidebar must be mocked for isolation:
// Don't assert on the mock - test Page's behavior with sidebar present
test('page layout includes sidebar area', () => {
  render(<Page />);  // Sidebar mocked for speed
  expect(screen.getByRole('main')).toHaveClass('with-sidebar-layout');
});

[Python/pytest]

# ✅ GOOD: Test real behavior with test double
class FakeMailer:
    def __init__(self):
        self.sent_emails = []

    def send_email(self, to: str, subject: str, body: str):
        self.sent_emails.append({"to": to, "subject": subject, "body": body})

def test_send_welcome_email_sends_correct_content():
    mailer = FakeMailer()

    send_welcome_email(mailer, "user@example.com")

    # Assert on REAL behavior
    assert len(mailer.sent_emails) == 1
    email = mailer.sent_emails[0]
    assert email["to"] == "user@example.com"
    assert email["subject"] == "Welcome!"
    assert "Thank you for signing up" in email["body"]

Detection Strategy

Red flags (TypeScript/Jest):

• Assertions check for *-mock in test IDs
• Test IDs contain "mock", "stub", "fake"
• Test fails when you remove the mock
• Can't explain what real behavior you're testing

Red flags (Python/pytest):

• mock.assert_called()
• mock.assert_called_once()
• mock.assert_called_with(...)
• mock.call_count assertions
• Testing .called or .call_args attributes

Gate Function:

BEFORE asserting on any mock element:
  Ask: "Am I testing real component behavior or just mock existence?"

  IF testing mock existence:
    STOP - Delete the assertion or unmock the component

  Ask: "What would this test verify in production?"

  IF answer is "nothing" or unclear:
    STOP - Rethink what you're testing

  Test real behavior instead

When Mocking is Appropriate

Good reasons to mock:

• Isolate slow external dependencies (network, filesystem, DB)
• Control non-deterministic behavior (time, randomness)
• Simulate error conditions hard to trigger
• Speed up test execution

Bad reasons to mock:

• "Might be slow" (without measuring)
• "To be safe"
• "Everyone mocks this"
• To avoid understanding dependencies

Rule: Mock at the boundary of slow/external operations, not high-level application logic.

Anti-Pattern 2: Test-Only Methods in Production

The Violation

[TypeScript/Jest]

// ❌ BAD: destroy() only used in tests
class Session {
  async destroy() {  // Looks like production API!
    await this._workspaceManager?.destroyWorkspace(this.id);
    await this._messageRouter?.cleanup();
    this._isDestroyed = true;
  }
}

// In tests
afterEach(() => session.destroy());

[Python/pytest]

# ❌ BAD: Test-only method in production class
class UserService:
    def __init__(self, db: Database):
        self._db = db

    def create_user(self, email: str) -> User:
        return self._db.insert_user(email)

    # Test-only method!
    def _set_mock_db(self, mock_db):
        """For testing only"""
        self._db = mock_db

Why this is wrong:

• Production class polluted with test-only code
• Dangerous if accidentally called in production
• Violates YAGNI (You Aren't Gonna Need It)
• Violates separation of concerns
• Breaks encapsulation
• Creates maintenance burden (unused code in production)

The Fix

[TypeScript/Jest]

// ✅ GOOD: Test utilities handle test cleanup
// Session has no destroy() - it's stateless in production

// In test-utils/session-helpers.ts
export async function cleanupSession(session: Session) {
  const workspace = session.getWorkspaceInfo();
  if (workspace) {
    await workspaceManager.destroyWorkspace(workspace.id);
  }

  const router = session.getMessageRouter();
  if (router) {
    await router.cleanup();
  }
}

// In tests
afterEach(() => cleanupSession(session));

[Python/pytest]

# ✅ GOOD: Dependency injection, no test-only methods
class UserService:
    def __init__(self, db: Database):
        self._db = db  # Injected dependency

    def create_user(self, email: str) -> User:
        return self._db.insert_user(email)

# test_user_service.py
class FakeDatabase:
    def __init__(self):
        self.users = []

    def insert_user(self, email: str) -> User:
        user = User(id=len(self.users) + 1, email=email)
        self.users.append(user)
        return user

def test_create_user():
    fake_db = FakeDatabase()
    service = UserService(fake_db)

    user = service.create_user("test@example.com")

    assert user.email == "test@example.com"
    assert len(fake_db.users) == 1

When Test Utilities Make Sense

Good candidates for test utilities:

• Setup/teardown operations
• Test data builders
• Assertion helpers
• Test-specific configurations
• Lifecycle management for tests

Keep in production:

• Methods used by application code
• Proper public API
• Business logic
• Real lifecycle methods (close, dispose)

Key distinction: If it's never called outside test files, it shouldn't be in production code.

Detection Strategy

Red flags (TypeScript/Jest):

• Method only called in *.test.* or *.spec.* files
• Method name suggests testing (reset, clear, destroy, mock)
• Comments say "for testing only"
• Method has no production use case

Red flags (Python/pytest):

• Methods named _set_*, _mock_*, _for_testing
• Docstrings saying "For testing only"
• if os.getenv('TESTING') conditionals
• Properties that exist only for test access

Gate Function:

BEFORE adding any method to production class:
  Ask: "Is this only used by tests?"

  IF yes:
    STOP - Don't add it
    Put it in test utilities instead (test-utils/, test-helpers/)

  Ask: "Does this class own this resource's lifecycle?"

  IF no:
    STOP - Wrong class for this method
    Resource owner should manage lifecycle

  Ask: "Would production code ever call this?"

  IF no:
    STOP - Belongs in test utilities

Refactoring Existing Test-Only Methods

Step-by-step:

1. Identify - Find methods only called in test files 2. Extract - Create test utility function with same logic 3. Migrate - Update tests to use utility 4. Remove - Delete test-only method from production 5. Verify - Production builds/bundles are cleaner

Example refactoring:

// Before: Production class polluted
class Database {
  async reset() { /* only for tests */ }
}

// After: Clean separation
// database.ts - production
class Database {
  // No reset() method
}

// test-utils/database.ts - tests only
export async function resetTestDatabase(db: Database) {
  // Use public API to achieve reset
  await db.executeRaw('TRUNCATE ALL TABLES');
}

Anti-Pattern 3: Mocking Without Understanding

The Violation

[TypeScript/Jest]

// ❌ BAD: Mock breaks test logic
test('detects duplicate server', async () => {
  // Mock prevents config write that test depends on!
  vi.mock('ToolCatalog', () => ({
    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined)
  }));

  await addServer(config);
  await addServer(config);  // Should throw - but won't!
  // Test expects duplicate detection, but mock broke it
});

[Python/pytest]

# ❌ BAD: Mocking without understanding side effects
@patch('user_service.send_email')
def test_user_registration(mock_send_email):
    register_user("test@example.com", "password123")

    # Didn't realize send_email also logs to analytics
    # Didn't realize send_email creates async task
    # Test passes but misses important behavior
    mock_send_email.assert_called_once()

Why this is wrong:

• Mocked method had side effects test depended on
• Over-mocking to "be safe" breaks actual behavior
• Test passes for wrong reason or fails mysteriously
• You're testing mock behavior, not real behavior

The Fix

[TypeScript/Jest]

// ✅ GOOD: Mock at correct level
test('detects duplicate server', async () => {
  // Mock the slow part, preserve behavior test needs
  vi.mock('MCPServerManager'); // Just mock slow server startup
  // Config writing preserved - duplicate detection works

  await addServer(config);  // Config written
  await expect(addServer(config)).rejects.toThrow('already exists');
});

[Python/pytest]

# ✅ GOOD: Understand THEN mock minimally
def test_user_registration():
    # First, run WITHOUT mocks to understand behavior
    # Discovered: send_email logs analytics + creates task

    # Now mock only the external I/O
    with patch('user_service.EmailClient.send') as mock_smtp:
        register_user("test@example.com", "password123")

        # Verify real behavior (not just mock called)
        user = User.query.filter_by(email="test@example.com").first()
        assert user is not None
        assert user.email_verified is False

        # Analytics logged (real behavior preserved)
        assert Analytics.query.filter_by(event='user_registered').count() == 1

        # Email attempted (mock at I/O boundary)
        assert mock_smtp.called

Understanding Dependencies Before Mocking

Questions to ask BEFORE mocking:

1. What does the real method do?

• Read the implementation
• Check for side effects
• Identify return values
• Note error conditions

2. What side effects exist?

• Filesystem writes
• Database updates
• Cache modifications
• State changes
• Event emissions

3. What does THIS test need?

• Which side effects matter?
• What behavior am I testing?
• What can be safely isolated?

4. Where should I mock?

• At the boundary of slow operations
• Below the logic being tested
• At external system interfaces

Dependency Analysis Example

// Analyzing: Should I mock discoverAndCacheTools()?

// 1. Read implementation
async function discoverAndCacheTools(serverConfig) {
  const tools = await fetchToolsFromServer(serverConfig);  // Slow
  await cacheTools(serverConfig.id, tools);                // Side effect!
  return tools;
}

// 2. Identify side effects
// - Network call (slow)
// - Cache write (side effect tests may depend on)

// 3. Determine test needs
test('server registration prevents duplicates', () => {
  // Needs: Config persistence to detect duplicate
  // Doesn't need: Actual tool discovery (slow)
});

// 4. Mock at correct level
// ✅ Mock network, preserve cache
vi.mock('server-connection', () => ({
  fetchToolsFromServer: vi.fn().mockResolvedValue([])
}));
// cacheTools() runs - test logic intact

Gate Function

BEFORE mocking any method:
  STOP - Don't mock yet

  1. Ask: "What side effects does the real method have?"
     Action: Read implementation, list all side effects

  2. Ask: "Does this test depend on any of those side effects?"
     Action: Identify which side effects test logic needs

  3. Ask: "Do I fully understand what this test needs?"
     Action: Write down test's dependencies

  IF depends on side effects:
    Mock at lower level (the actual slow/external operation)
    OR use test doubles that preserve necessary behavior
    NOT the high-level method the test depends on

  IF unsure what test depends on:
    Run test with real implementation FIRST
    Observe what actually needs to happen
    THEN add minimal mocking at the right level

  Red flags:
    - "I'll mock this to be safe"
    - "This might be slow, better mock it"
    - Mocking without reading implementation
    - Mocking without understanding dependency chain

Levels of Mocking

Choose the right level:

[TypeScript/Jest]

// ❌ Too high - breaks test logic
vi.mock('UserService');  // Mocks everything, including state changes

// ❌ Too high - over-mocking
vi.mock('DatabaseAdapter');  // Could use in-memory DB instead

// ✅ Right level - isolates slow operation
vi.mock('HTTPClient');  // Mock network, preserve business logic

// ✅ Right level - controls non-determinism
vi.spyOn(Date, 'now').mockReturnValue(fixedTimestamp);

[Python/pytest]

# ❌ Too high - breaks test logic
@patch('user_service')  # Mocks entire module, including state

# ❌ Too high - over-mocking
@patch('user_service.UserRepository')  # Could use in-memory/test database

# ✅ Right level - isolates slow operation
@patch('requests.post')  # Mock network, preserve business logic

# ✅ Right level - controls non-determinism
@patch('time.time', return_value=1234567890)

Mocking hierarchy (top to bottom): 1. Application logic - Never mock (this is what you're testing) 2. Business layer - Rarely mock (needed for test assertions) 3. Adapter layer - Sometimes mock (if slow, use test doubles) 4. I/O boundaries - Usually mock (network, filesystem, external APIs) 5. Infrastructure - Always mock (actual servers, databases in unit tests)

Common Mocking Mistakes

Mistake 1: Mocking what you're testing

// ❌ BAD
test('user registration validates email', () => {
  vi.mock('UserValidator');  // You're testing this!
  await registerUser(email);
});

// ✅ GOOD
test('user registration validates email', () => {
  vi.mock('EmailService');  // Mock email sending, test validation
  await expect(registerUser('invalid')).rejects.toThrow();
});

Mistake 2: Mocking too broadly

// ❌ BAD - mocks entire module
vi.mock('./user-service');

// ✅ GOOD - mocks specific slow operation
vi.mock('./email-client', () => ({
  sendEmail: vi.fn()  // Just the network call
}));

Mistake 3: Mocking based on assumptions

// ❌ BAD - assumption without measurement
// "Database queries are slow, better mock"
vi.mock('./database');

// ✅ GOOD - measure first
// Run test unmocked: 2ms (fast enough!)
// Don't mock unless proven slow

Prevention Through TDD

How TDD prevents these anti-patterns:

1. Write test first → Forces you to think about what you're actually testing 2. Watch it fail → Confirms test tests real behavior, not mocks 3. Minimal implementation → No test-only methods creep in 4. Real dependencies → You see what the test actually needs before mocking

If you're testing mock behavior, you violated TDD - you added mocks without watching test fail against real code first.

TDD workflow prevents:

• Testing mock behavior (test fails for real reasons first)
• Test-only methods (minimal implementation doesn't add them)
• Uninformed mocking (you understand needs before mocking)

See the Test-Driven Development skill for complete TDD workflow (available in the skill library for comprehensive TDD guidance).

Detection Guide: Identifying Testing Anti-Patterns

Comprehensive guide for detecting testing anti-patterns before they cause problems. Includes red flags, warning signs, gate functions, and diagnostic checklists.

Overview

Prevention is easier than cure. This guide helps you identify anti-patterns during code review, test writing, or debugging test failures.

Universal Detection Checklist

Run 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

□ Can I explain what real behavior this test verifies?
  → If no: STOP - Clarify what you're testing

□ Would this test fail if I removed mocks?
  → If no: You're testing mock behavior

Anti-Pattern 1: Testing Mock Behavior

Red Flags

[TypeScript/Jest]

// 🚩 Test ID contains "mock"
expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();

// 🚩 Asserting mock was called
expect(mockFunction).toHaveBeenCalled();

// 🚩 Checking mock return values
expect(result).toBe(mockReturnValue);

// 🚩 Test fails when mock removed
// Remove mock → test fails → you're testing mock

[Python/pytest]

# 🚩 Asserting on mock call behavior
mock_mailer.send_email.assert_called()
mock_mailer.send_email.assert_called_once()
mock_mailer.send_email.assert_called_with("user@example.com", "Welcome!")

# 🚩 Checking mock attributes
assert mock_mailer.send_email.called
assert mock_mailer.send_email.call_count == 1

# 🚩 Test fails when mock removed
# Remove mock → test fails → you're testing mock

Language patterns:

• "Make sure the mock..."
• "Test that component renders mock"
• "Verify mock is present"
• "Check if mock function called"

Diagnostic questions: 1. "If I remove this mock, does test still make sense?"

• No → You're testing mock behavior
• Yes → Good, test tests real behavior

2. "What production behavior does this verify?"

• Can't answer → Testing mock behavior
• Clear answer → Good

3. "Would this test catch real bugs?"

• No → Testing mock behavior
• Yes → Good

Detection Script

// Run this check on your tests
function detectsMockTesting(testFile: string): string[] {
  const warnings: string[] = [];

  // Pattern: testId with 'mock'
  if (testFile.includes("getByTestId('") && testFile.includes('-mock')) {
    warnings.push('Testing mock element by test ID');
  }

  // Pattern: expecting on mock objects
  if (testFile.includes('expect(mock') && testFile.includes('toBe')) {
    warnings.push('Asserting on mock values');
  }

  // Pattern: mock call assertions without behavior check
  if (testFile.includes('toHaveBeenCalled') &&
      !testFile.includes('expect(result)')) {
    warnings.push('Only checking mock calls, not results');
  }

  return warnings;
}

Anti-Pattern 2: Test-Only Methods in Production

Red Flags

[TypeScript/Jest]

// 🚩 Method only called in test files
// Search: "destroy(" → Only in *.test.ts files

// 🚩 Method names suggesting test use
class Session {
  reset()    // 🚩
  destroy()  // 🚩
  clear()    // 🚩
  mock()     // 🚩
}

// 🚩 Comments acknowledging test-only use
// "For testing only"
// "Used by test cleanup"

[Python/pytest]

# 🚩 Methods only called in test files
# Search: "_set_mock" → Only in test_*.py files

# 🚩 Method names suggesting test use
class UserService:
    def _set_mock_db(self, db):  # 🚩
        pass
    def _reset_for_testing(self):  # 🚩
        pass
    def _mock_dependencies(self):  # 🚩
        pass

# 🚩 Docstrings acknowledging test-only use
"""For testing only"""
"""Used by test fixtures"""

File analysis:

[TypeScript/Jest]

# Find methods only called in tests
grep -r "\.destroy\(" --include="*.ts" | grep -v ".test.ts"
# If empty → method only in tests → move to test utils

[Python/pytest]

# Find methods only called in tests
grep -r "\._set_mock" --include="*.py" | grep -v "test_"
# If empty → method only in tests → move to test utils

Diagnostic questions: 1. "Is this method called outside test files?"

• No → Test-only method, move to utilities
• Yes → Keep in production

2. "Would production code ever need this?"

• No → Move to test utilities
• Yes → Keep in production

3. "Does this class own this resource's lifecycle?"

• No → Wrong place for this method
• Yes → Consider if needed in production

Detection Script

// Analyze method usage
function findTestOnlyMethods(codebase: string[]): Report {
  const methods = extractMethods(codebase);

  return methods.filter(method => {
    const usages = findUsages(method);
    const testUsages = usages.filter(u => u.file.includes('.test.'));
    const prodUsages = usages.filter(u => !u.file.includes('.test.'));

    return testUsages.length > 0 && prodUsages.length === 0;
  });
}

Anti-Pattern 3: Mocking Without Understanding

Red Flags

Code indicators:

// 🚩 Mocking without reading implementation
vi.mock('SomeModule');  // What does it do? Unknown.

// 🚩 "Just to be safe" mocking
// Mock everything, understand nothing

// 🚩 Test mysteriously fails/passes
// You can't explain why

// 🚩 Mock prevents test logic from working
vi.mock('UserService');  // Breaks user creation test needs

Language patterns:

• "I'll mock this to be safe"
• "This might be slow"
• "Let's mock everything"
• "Not sure why test fails"

Diagnostic questions: 1. "What side effects does the real method have?"

• Can't answer → Don't mock yet
• Know all effects → Can mock safely

2. "Does my test depend on any of those side effects?"

• Yes → Don't mock at this level
• No → Safe to mock

3. "Where is the actual slow/external operation?"

• Unclear → Study code first
• Clear → Mock at that level

Detection Strategy

Before mocking:

1. Read the implementation
   - What does it do?
   - What are side effects?
   - What does it return?

2. Run test with real implementation
   - How slow is it? (measure!)
   - What behavior occurs?
   - What's actually needed?

3. Identify minimal mock point
   - Where is the slow/external operation?
   - Can I mock below this level?
   - What behavior must be preserved?

4. Mock at correct level
   - Mock boundary of slow operation
   - Preserve logic test depends on
   - Verify test still tests intended behavior

Speed Measurement

// Measure before mocking
test('user registration', async () => {
  const start = performance.now();
  await registerUser(userData);
  const duration = performance.now() - start;

  console.log(`Test took ${duration}ms`);
  // If <100ms → Don't mock
  // If >1000ms → Identify slow part
});

Anti-Pattern 4: Incomplete Mocks

Red Flags

Code indicators:

// 🚩 Mock created from memory
const mock = { id: '123' };  // What other fields exist?

// 🚩 Partial type annotation
const mock: Partial<User> = { id: '123' };

// 🚩 Different tests, different mock shapes
// test1.ts: { id, name }
// test2.ts: { id, name, email, profile }

// 🚩 Comment acknowledging incompleteness
// "TODO: add more fields"
// "Add fields as needed"

Missing documentation:

• No reference to API docs
• No TypeScript interface
• No factory function
• Copy-pasted mock variations

Diagnostic questions: 1. "What does the real API return?"

• Can't answer → Check docs before mocking
• Know structure → Use it in mock

2. "Am I using TypeScript types?"

• No → Add types to enforce completeness
• Yes → Good

3. "Do other tests mock this differently?"

• Yes → Inconsistent mocks, need factory
• No → Good

Detection Script

// Find incomplete mocks
function detectIncompleteMocks(testFile: string): Warning[] {
  const warnings: Warning[] = [];

  // Pattern: Partial<T> in test
  if (testFile.includes('Partial<') && testFile.includes('mock')) {
    warnings.push('Using Partial type for mock - likely incomplete');
  }

  // Pattern: Object literals without types
  const mockPattern = /const mock\w+ = \{[^}]+\};/g;
  const mocks = testFile.match(mockPattern);

  if (mocks) {
    mocks.forEach(mock => {
      if (!mock.includes(': ')) {  // No type annotation
        warnings.push('Mock without type annotation');
      }
    });
  }

  return warnings;
}

Completeness Checklist

□ Referenced API documentation
□ Used TypeScript interface/type
□ Included all required fields
□ Included optional fields (as null/undefined)
□ Nested objects complete
□ Arrays have realistic length/content
□ Metadata fields included
□ Timestamps/IDs present

Anti-Pattern 5: Tests as Afterthought

Red Flags

Process indicators:

🚩 PR has implementation commits, then "add tests" commit
🚩 "Ready for testing" status on untested feature
🚩 Test coverage added after code review
🚩 Tests written to pass, not fail first
🚩 Implementation complete, tests pending

Language patterns:

• "I'll add tests next"
• "Implementation done, needs tests"
• "Ready for testing phase"
• "Tests coming soon"

Code indicators:

// 🚩 Tests that can't fail
test('feature works', () => {
  const result = newFeature();
  expect(result).toBe(result);  // Always passes
});

// 🚩 Tests with no assertions
test('feature runs', () => {
  newFeature();  // No expect()
});

Diagnostic questions: 1. "Did I write test before implementation?"

• No → Not following TDD
• Yes → Good

2. "Did I watch test fail first?"

• No → Can't verify test works
• Yes → Good

3. "Are there commits without tests?"

• Yes → Tests afterthought
• No → Good

Git History Analysis

# Check if tests come after implementation
git log --oneline --name-only | grep -A5 "feature"

# Red flag pattern:
# abc123 Add feature X
#   src/feature.ts
# def456 Add tests for feature X  ← Tests after
#   src/feature.test.ts

# Good pattern:
# abc123 Add feature X with tests
#   src/feature.test.ts  ← Test file in same commit
#   src/feature.ts

Warning Signs: When Mocks Become Too Complex

Complexity Indicators

// 🚩 Mock setup longer than test
const setup = 50 lines;
const test = 10 lines;
// Ratio > 3:1 → Too complex

// 🚩 Mocking everything
vi.mock('ModuleA');
vi.mock('ModuleB');
vi.mock('ModuleC');
vi.mock('ModuleD');
// 4+ mocks → Consider integration test

// 🚩 Nested mock setup
const mockA = { mock: mockB };
const mockB = { mock: mockC };
const mockC = { /* ... */ };

// 🚩 Mock setup in beforeEach for single test
beforeEach(() => {
  // 30 lines of setup
});

test('one thing', () => {
  // 5 lines
});

Your human partner's question: "Do we need to be using a mock here?"

Consider: Integration tests with real components often simpler than complex mocks.

Complexity Metrics

function calculateMockComplexity(test: TestFile): ComplexityScore {
  return {
    mockCount: countMocks(test),           // >4 is high
    setupLines: countSetupLines(test),     // >30 is high
    setupToTestRatio: setupLines / testLines,  // >3 is high
    mockNestingDepth: calculateNesting(test),  // >2 is high

    recommendation: score > 10 ? 'Use integration test' : 'OK'
  };
}

Comprehensive Code Review Checklist

Use this when reviewing tests (yours or others'):

Structure

□ Test files exist for new code
□ Tests in same commit as implementation
□ Tests follow TDD pattern (fail first)
□ Clear test names describe behavior

Mock Usage

□ Mocks used sparingly (only when needed)
□ Mock setup is simple (<20 lines)
□ Mocks at correct level (I/O boundaries)
□ No assertions on mock elements
□ Complete mock structures (all fields)

Production Code

□ No test-only methods in production classes
□ No test-specific logic in production
□ Clean separation of concerns
□ No test imports in production code

Test Quality

□ Tests verify real behavior
□ Assertions on meaningful results
□ Edge cases covered
□ Error conditions tested
□ Integration tests for critical paths

Red Flags

□ No 'testId="*-mock"' assertions
□ No Partial<T> for mocks
□ No "for testing" comments in production
□ No untested implementation commits

Automated Detection Tools

ESLint Rules

// .eslintrc.js
module.exports = {
  rules: {
    // Prevent test-only methods
    'no-restricted-syntax': [
      'error',
      {
        selector: 'MethodDefinition[key.name=/^(reset|destroy|clear|mock)$/]',
        message: 'Potential test-only method in production code'
      }
    ],

    // Prevent mock test IDs
    'testing-library/prefer-screen-queries': 'error',
    'testing-library/no-node-access': 'error',
  }
};

Pre-commit Hook

#!/bin/bash
# .git/hooks/pre-commit

# Check for mock test IDs
if git diff --cached | grep -q "testId=.*-mock"; then
  echo "Error: Found mock test ID in tests"
  echo "Are you testing mock behavior?"
  exit 1
fi

# Check for test-only methods
if git diff --cached -- "*.ts" "*.js" | \
   grep -v ".test." | \
   grep -q "destroy()\|reset()\|clear()"; then
  echo "Warning: Potential test-only method in production code"
fi

# Check test coverage
npm test -- --coverage --coverageThreshold='{"global":{"lines":80}}'

Quick Reference: Detection Summary

Python/pytest-Specific Detection Patterns

Red Flags Unique to Python

Over-reliance on unittest.mock:

# 🚩 Using Mock() for data objects
mock_user = Mock()
mock_user.id = 123
mock_user.name = "Alice"
# Should use dataclass or fixture factory instead

# 🚩 MagicMock without spec
mock_service = MagicMock()
# Should specify spec=RealService to catch attribute errors

# 🚩 Global @patch decorators
@patch('module.function1')
@patch('module.function2')
@patch('module.function3')
def test_something(...):
    # Too broad - over-mocking

Fixture Abuse:

# 🚩 autouse fixtures without clear need
@pytest.fixture(autouse=True)
def setup_everything():
    # Hidden dependency - tests unclear

# 🚩 Fixture bloat
@pytest.fixture
def user(db, session, config, mailer, cache, queue):
    # Too many dependencies

# 🚩 Complex fixture chains
@pytest.fixture
def user(profile, settings, permissions):
    # Each has more fixtures - hard to understand

pytest-mock Patterns:

# 🚩 Mocking at wrong level
mocker.patch('user_service.UserRepository')  # Too high
# Should mock database connection, not repository

# 🚩 Missing spec parameter
mocker.patch('requests.post')  # No spec
# Should use spec=requests.post or spec_set

# 🚩 Asserting on mock calls without behavior check
mock_mailer.send_email.assert_called_once()
# But no assertion on actual result!

Python Detection Script

# Check for anti-patterns in Python tests
def detect_python_anti_patterns(test_file: str) -> list[str]:
    warnings = []

    # Pattern: Mock assertions without behavior checks
    if '.assert_called' in test_file and 'assert ' not in test_file:
        warnings.append('Mock assertions without real behavior checks')

    # Pattern: Using Mock() for data objects
    if 'Mock()' in test_file and 'dataclass' not in test_file:
        warnings.append('Using Mock() for data - use dataclass/fixture')

    # Pattern: @patch without spec
    if '@patch(' in test_file and 'spec=' not in test_file:
        warnings.append('@patch without spec parameter')

    # Pattern: Too many autouse fixtures
    autouse_count = test_file.count('autouse=True')
    if autouse_count > 2:
        warnings.append(f'{autouse_count} autouse fixtures - hidden dependencies')

    return warnings

pytest Best Practices Checklist

□ Use fixtures instead of mocks when possible
□ Specify spec= on @patch decorators
□ Use dataclasses/factories for test data, not Mock()
□ Limit autouse fixtures to truly global setup
□ Prefer monkeypatch over @patch for simple cases
□ Use parametrize instead of loops
□ Keep fixture chains shallow (<3 levels)
□ Mock at I/O boundaries (requests, database), not business logic

When to Seek Help

STOP and ask your human partner if:

• Mock setup exceeds 50 lines
• You've mocked >5 modules in one test
• Test mysteriously passes/fails
• You can't explain what test verifies
• Same test needs different mocks in different runs
• Integration test seems simpler than mocks
• Fixture chain depth >3 levels (Python/pytest)
• Using Mock() for data objects (Python)

Questions to ask:

• "Do we need to be using a mock here?"
• "Should this be an integration test?"
• "Am I testing the right thing?"
• "Is this test-only method necessary?"
• "Should this be a fixture instead of a mock?" (Python/pytest)
• "Can I use a fake/test double instead?" (Python/pytest)

Prevention Mindset

Before writing any test: 1. Understand what you're testing (real behavior) 2. Write test first (TDD) 3. Watch it fail 4. Minimal implementation 5. Watch it pass 6. Refactor

This workflow prevents all five anti-patterns naturally.

See the Test-Driven Development skill for complete TDD workflow (available in the skill library for comprehensive TDD guidance).

Testing Anti-Patterns in Python

How the core testing anti-patterns manifest in Python with pytest and unittest.mock.

Anti-Pattern 1: Testing Mock Behavior

Python Example

# ❌ BAD - Testing mock behavior, not real code
from unittest.mock import Mock, patch

def test_send_email():
    mock_mailer = Mock()
    
    # System under test
    send_welcome_email(mock_mailer, "user@example.com")
    
    # Asserting on MOCK behavior
    assert mock_mailer.send_email.called  # Testing the mock!
    assert mock_mailer.send_email.call_count == 1
    mock_mailer.send_email.assert_called_with("user@example.com", "Welcome!")

What's wrong: Test passes if mock is called, but doesn't verify send_welcome_email actually works correctly.

The fix:

# ✅ GOOD - Test real behavior with test double
class FakeMailer:
    def __init__(self):
        self.sent_emails = []
    
    def send_email(self, to: str, subject: str, body: str):
        self.sent_emails.append({"to": to, "subject": subject, "body": body})

def test_send_welcome_email_sends_correct_content():
    mailer = FakeMailer()
    
    send_welcome_email(mailer, "user@example.com")
    
    # Assert on REAL behavior
    assert len(mailer.sent_emails) == 1
    email = mailer.sent_emails[0]
    assert email["to"] == "user@example.com"
    assert email["subject"] == "Welcome!"
    assert "Thank you for signing up" in email["body"]

Detection in Python

Red flags:

• mock.assert_called()
• mock.assert_called_once()
• mock.assert_called_with(...)
• mock.call_count
• Testing .called or .call_args

Gate function:

# Before writing test with mocks
def check_test_validity():
    """
    Q: Am I asserting on mock methods (.called, .call_count)?
    YES → STOP - You're testing the mock
    NO → Proceed
    """

Anti-Pattern 2: Test-Only Methods in Production

Python Example

# ❌ BAD - Test-only method in production class
class UserService:
    def __init__(self, db: Database):
        self._db = db
    
    def create_user(self, email: str) -> User:
        return self._db.insert_user(email)
    
    # Test-only method!
    def _set_mock_db(self, mock_db):
        """For testing only"""
        self._db = mock_db

What's wrong: Production code polluted with test concerns. Breaks encapsulation.

The fix:

# ✅ GOOD - Dependency injection, no test-only methods
class UserService:
    def __init__(self, db: Database):
        self._db = db  # Injected dependency
    
    def create_user(self, email: str) -> User:
        return self._db.insert_user(email)

# test_user_service.py
class FakeDatabase:
    def __init__(self):
        self.users = []
    
    def insert_user(self, email: str) -> User:
        user = User(id=len(self.users) + 1, email=email)
        self.users.append(user)
        return user

def test_create_user():
    fake_db = FakeDatabase()
    service = UserService(fake_db)
    
    user = service.create_user("test@example.com")
    
    assert user.email == "test@example.com"
    assert len(fake_db.users) == 1

Detection in Python

Red flags:

• Methods named _set_*, _mock_*, _for_testing
• Docstrings saying "For testing only"
• if os.getenv('TESTING') conditionals
• Properties that exist only for test access

Anti-Pattern 3: Mocking Without Understanding

Python Example

# ❌ BAD - Mocking without understanding side effects
@patch('user_service.send_email')
def test_user_registration(mock_send_email):
    register_user("test@example.com", "password123")
    
    # Didn't realize send_email also logs to analytics
    # Didn't realize send_email creates async task
    # Test passes but misses important behavior
    mock_send_email.assert_called_once()

What's wrong: Mocked send_email without understanding it logs analytics and creates background tasks.

The fix:

# ✅ GOOD - Understand THEN mock minimally
def test_user_registration():
    # First, run WITHOUT mocks to understand behavior
    # Discovered: send_email logs analytics + creates task
    
    # Now mock only the external I/O
    with patch('user_service.EmailClient.send') as mock_smtp:
        register_user("test@example.com", "password123")
        
        # Verify real behavior (not just mock called)
        user = User.query.filter_by(email="test@example.com").first()
        assert user is not None
        assert user.email_verified is False
        
        # Analytics logged (real behavior preserved)
        assert Analytics.query.filter_by(event='user_registered').count() == 1
        
        # Email attempted (mock at I/O boundary)
        assert mock_smtp.called

Detection in Python

Red flags:

• @patch decorators without trying test first
• Mocking entire modules (@patch('user_service'))
• Mocking internal functions in the same module
• Mock setup longer than test code

Gate function:

# Before adding @patch
def check_mock_necessity():
    """
    Q: Did I run test WITHOUT mock first?
    NO → STOP - Run without mock to understand
    YES → Proceed with minimal mocking
    
    Q: Am I mocking internal code or external I/O?
    INTERNAL → STOP - Don't mock what you're testing
    EXTERNAL → Proceed
    """

Anti-Pattern 4: Incomplete Mocks

Python Example

# ❌ BAD - Incomplete mock missing fields
from unittest.mock import Mock

def test_display_user_profile():
    mock_user = Mock()
    mock_user.id = 123
    mock_user.name = "Alice"
    # Missing: email, profile, metadata
    
    result = display_user_profile(mock_user)
    
    # Test passes but production code may access user.profile.timezone
    # → AttributeError in production!

The fix:

# ✅ GOOD - Complete mock or use fixture
from dataclasses import dataclass
from typing import Optional

@dataclass
class User:
    id: int
    name: str
    email: str
    profile: 'UserProfile'
    metadata: dict

@dataclass
class UserProfile:
    timezone: str
    locale: str
    avatar: Optional[str]

# Fixture factory
def create_test_user(**overrides) -> User:
    """Complete user with all required fields"""
    defaults = {
        "id": 123,
        "name": "Alice",
        "email": "alice@example.com",
        "profile": UserProfile(
            timezone="UTC",
            locale="en-US",
            avatar=None
        ),
        "metadata": {}
    }
    return User(**{**defaults, **overrides})

def test_display_user_profile():
    user = create_test_user(name="Alice", profile__timezone="America/New_York")
    
    result = display_user_profile(user)
    
    assert "Alice" in result
    assert "America/New_York" in result

Detection in Python

Red flags:

• Using Mock() for data objects
• Setting only a few attributes on mocks
• No type hints on mock objects
• Different tests have different mock shapes for same type

Prevention:

# Use pytest fixtures or factory functions
import pytest

@pytest.fixture
def user():
    """Complete User fixture with all fields"""
    return create_test_user()

def test_with_fixture(user):
    # user has all required fields
    result = process_user(user)
    assert result.email == "alice@example.com"

Anti-Pattern 5: Tests as Afterthought

Python Example

# ❌ BAD - Implementation before tests
# 1. Wrote create_user() function
# 2. Wrote update_user() function  
# 3. Wrote delete_user() function
# 4. Now writing tests to achieve coverage

def test_create_user():
    # Test confirms what code DOES, not what it SHOULD do
    # Bugs baked into test expectations
    pass

The fix - TDD:

# ✅ GOOD - Test first (TDD)

# Step 1: RED - Write failing test
def test_create_user_validates_email():
    with pytest.raises(ValidationError):
        create_user("invalid-email")
    # ❌ Test fails - create_user doesn't exist

# Step 2: GREEN - Minimal implementation
def create_user(email: str) -> User:
    if "@" not in email:
        raise ValidationError("Invalid email")
    return User(email=email)
    # ✅ Test passes

# Step 3: REFACTOR - Improve without breaking test
def create_user(email: str) -> User:
    validate_email(email)  # Extracted validation
    return User(email=email)
    # ✅ Test still passes

Python TDD Workflow

# Complete TDD cycle
class TestUserRegistration:
    def test_user_registration_creates_user(self):
        # RED: Test fails
        result = register_user("test@example.com", "password123")
        assert result.success is True
        # ❌ register_user doesn't exist
    
    def test_user_registration_sends_welcome_email(self):
        # RED: Test fails
        fake_mailer = FakeMailer()
        register_user("test@example.com", "password123", mailer=fake_mailer)
        assert len(fake_mailer.sent_emails) == 1
        # ❌ Function doesn't send email yet
    
    # Implement register_user() to make tests GREEN
    # Then refactor while keeping tests GREEN

pytest-Specific Patterns

Use Fixtures, Not Mocks

# ❌ BAD - Mocking database
@patch('app.database')
def test_get_user(mock_db):
    mock_db.query.return_value = Mock(id=1, name="Alice")
    # Testing mock behavior

# ✅ GOOD - Test database fixture
@pytest.fixture
def db():
    """In-memory SQLite for fast tests"""
    engine = create_engine("sqlite:///:memory:")
    Base.metadata.create_all(engine)
    session = Session(engine)
    yield session
    session.close()

def test_get_user(db):
    # Insert real data
    db.add(User(id=1, name="Alice"))
    db.commit()
    
    # Test real behavior
    user = get_user(db, user_id=1)
    assert user.name == "Alice"

pytest-mock Plugin

# When you MUST mock, use pytest-mock
def test_api_call_retries(mocker):
    # Mock at I/O boundary
    mock_requests = mocker.patch('requests.post')
    mock_requests.side_effect = [
        ConnectionError(),  # First attempt fails
        ConnectionError(),  # Second attempt fails
        Mock(status_code=200, json=lambda: {"success": True})  # Third succeeds
    ]
    
    result = call_api_with_retry("https://api.example.com/data")
    
    assert mock_requests.call_count == 3
    assert result["success"] is True

Parametrize Instead of Mocking

# ❌ BAD - Mocking to test different values
def test_with_various_inputs():
    for value in [1, 2, 3]:
        mock_input = Mock(return_value=value)
        # Complex mock setup

# ✅ GOOD - Parametrize
@pytest.mark.parametrize("input_value,expected", [
    (1, "one"),
    (2, "two"),
    (3, "three"),
])
def test_number_to_word(input_value, expected):
    assert number_to_word(input_value) == expected

Python-Specific Red Flags

Watch for:

• unittest.mock.Mock() for data objects → Use dataclasses
• @patch on every test → Over-mocking
• MagicMock without spec → Incomplete mocks
• mock.return_value = ... without types → Missing validation
• Global @patch decorators → Broad mocking
• patch.object() on system under test → Testing your own code

Prevention checklist:

# Before using unittest.mock
□ Can I use a fixture instead of a mock?
□ Can I use a fake/test double instead?
□ Am I mocking at the I/O boundary, not internal code?
□ Did I run the test WITHOUT mocks first?
□ Do I understand what I'm mocking?
□ Is my mock complete (all fields/methods)?

When Mocking Is Appropriate in Python

✅ Mock these:

• External HTTP calls (requests.post)
• Database connections in unit tests (psycopg2.connect)
• File system operations (open, os.path.exists)
• Time/datetime (datetime.now, time.time)
• Random number generation (random.random)
• Environment variables (os.getenv)

❌ Don't mock these:

• Your own business logic
• Data classes or models
• Internal helper functions
• Anything you're testing
• SQLAlchemy models (use test DB instead)
• Serializers/deserializers

Quick Reference

How TDD Prevents Testing Anti-Patterns

Test-Driven Development (TDD) is not just a testing methodology - it's a design methodology that naturally prevents all five testing anti-patterns. This guide explains the deep connection between TDD and anti-pattern prevention.

Overview

Core insight: If you follow strict TDD, testing anti-patterns become nearly impossible to create.

Why: TDD forces you to think about real behavior before implementation, making mock-testing and test-only methods unnatural.

TDD Fundamentals

The RED/GREEN/REFACTOR Cycle

1. RED: Write failing test
   - Test doesn't compile or fails
   - Verify failure reason is correct
   - No implementation exists yet

2. GREEN: Write minimal code to pass
   - Simplest implementation
   - Just enough to pass test
   - No gold plating

3. REFACTOR: Improve code
   - Clean up duplication
   - Improve names
   - Tests still pass

4. REPEAT: Next test

Critical rule: Never write implementation without failing test first.

See the Test-Driven Development skill for complete workflow (available in the skill library for comprehensive TDD guidance).

How TDD Prevents Each Anti-Pattern

Anti-Pattern 1: Testing Mock Behavior

How TDD prevents it:

TDD Step 1: Write test for real behavior
  ↓
Test fails because feature doesn't exist
  ↓
TDD Step 2: Implement minimal code
  ↓
Test passes - you tested real code, not mock

If you tested mock:
  ↓
Test would pass immediately (mock exists)
  ↓
Violation of TDD - didn't see failure

Example workflow:

// TDD Step 1: Write failing test
test('renders sidebar with navigation', () => {
  render(<Page />);
  expect(screen.getByRole('navigation')).toBeInTheDocument();
});
// ❌ Fails - Page doesn't render sidebar yet

// TDD Step 2: Implement
function Page() {
  return <div><Sidebar role="navigation" /></div>;
}
// ✅ Passes - tested real component

// WRONG way (not TDD):
test('renders sidebar mock', () => {
  render(<Page />);
  expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();
});
// ✅ Passes immediately - you never saw it fail!
// This violates TDD - test must fail first

TDD guarantee: If test passes immediately, you're testing mock behavior.

Anti-Pattern 2: Test-Only Methods in Production

How TDD prevents it:

TDD Step 1: Write test for needed behavior
  ↓
Test describes what production needs
  ↓
TDD Step 2: Minimal implementation
  ↓
Only code test needs is written

If method only for tests:
  ↓
No production test would need it
  ↓
TDD wouldn't add it

Example workflow:

// TDD Step 1: Write test for production behavior
test('session expires after timeout', async () => {
  const session = new Session();
  await advanceTime(SESSION_TIMEOUT);
  expect(session.isActive()).toBe(false);
});
// ❌ Fails - Session doesn't handle expiry

// TDD Step 2: Implement expiry (production feature)
class Session {
  isActive() {
    return Date.now() < this.expiresAt;
  }
}
// ✅ Passes - implemented real behavior

// WRONG way (not TDD):
// "I need to cleanup in tests"
class Session {
  destroy() { /* for tests */ }  // ❌ Not driven by test!
}

TDD guarantee: Minimal implementation doesn't add untested code.

Test cleanup belongs in test utilities:

// test-utils/session.ts
export async function cleanupSession(session: Session) {
  // Use public API for cleanup
  session.logout();
  // Clear any test-specific state
}

Anti-Pattern 3: Mocking Without Understanding

How TDD prevents it:

TDD Step 1: Write test with real implementation
  ↓
Test runs - you see what it does
  ↓
Identify what's slow/external
  ↓
TDD Step 2: Mock at correct level
  ↓
Mock only slow part, preserve behavior

If you mock first:
  ↓
Never saw real behavior
  ↓
Don't understand dependencies
  ↓
Mock breaks test logic

Example workflow:

// TDD Step 1: Write test with real implementation
test('detects duplicate server', async () => {
  await addServer(config);
  await expect(addServer(config))
    .rejects.toThrow('already exists');
});
// Run test - takes 2 seconds (server startup slow)
// Observe: Config written, duplicate detected
// Understand: Test depends on config persistence

// TDD Step 2: Mock at correct level
test('detects duplicate server', async () => {
  vi.mock('MCPServerManager');  // Mock slow startup only
  // Config writing preserved - test logic intact

  await addServer(config);
  await expect(addServer(config))
    .rejects.toThrow('already exists');
});
// ✅ Fast test, correct behavior

// WRONG way (not TDD):
// "Let me mock this upfront"
vi.mock('ToolCatalog', () => ({
  discoverAndCacheTools: vi.fn()  // Breaks test logic!
}));
// Never saw real behavior - don't know what test needs

TDD guarantee: You understand dependencies before mocking them.

Anti-Pattern 4: Incomplete Mocks

How TDD prevents it:

TDD Step 1: Write test with real API
  ↓
See complete response structure
  ↓
TDD Step 2: Mock with complete structure
  ↓
Test still passes - mock is complete

If mock incomplete:
  ↓
Test fails - mock missing fields
  ↓
TDD forces you to complete mock

Example workflow:

// TDD Step 1: Test with real API (or type)
test('displays user profile', async () => {
  const user = await api.getUser('123');
  // TypeScript shows complete User type
  render(<Profile user={user} />);
  expect(screen.getByText(user.name)).toBeInTheDocument();
  expect(screen.getByText(user.profile.timezone)).toBeInTheDocument();
});
// Observe complete structure

// TDD Step 2: Mock with complete structure
test('displays user profile', async () => {
  const mockUser: User = {  // TypeScript enforces completeness
    id: '123',
    name: 'Alice',
    email: 'alice@example.com',
    profile: {
      timezone: 'UTC',
      locale: 'en-US',
      avatar: null
    },
    metadata: { /* complete */ }
  };

  render(<Profile user={mockUser} />);
  expect(screen.getByText('Alice')).toBeInTheDocument();
});
// ✅ Complete mock, test passes

// WRONG way (not TDD):
const mockUser = { id: '123', name: 'Alice' };  // Incomplete
// Later breaks when profile.timezone accessed

TDD guarantee: Test with real data first reveals complete structure.

Use TypeScript to enforce completeness:

// Define complete type from API
interface User {
  id: string;
  name: string;
  email: string;
  profile: UserProfile;
  metadata: UserMetadata;
}

// TypeScript errors if incomplete
const mock: User = {
  id: '123',
  name: 'Alice'
  // ❌ TypeScript error - missing fields
};

Anti-Pattern 5: Tests as Afterthought

How TDD prevents it:

TDD Step 1: MUST write test first
  ↓
No implementation without test
  ↓
Test IS implementation process

If implementation first:
  ↓
Violated TDD - broke the cycle

TDD makes tests as afterthought impossible:

// TDD Way - tests ARE implementation
// 1. RED
test('user registration validates email', async () => {
  await expect(registerUser('invalid'))
    .rejects.toThrow('Invalid email');
});
// ❌ Fails - registerUser doesn't exist

// 2. GREEN
async function registerUser(email: string) {
  if (!isValidEmail(email)) {
    throw new Error('Invalid email');
  }
  // ... registration
}
// ✅ Passes

// 3. REFACTOR
// Improve validation logic, tests still pass

// NOT TDD (anti-pattern):
// 1. Implement registerUser
// 2. "Feature complete, need to add tests"  ← Afterthought

TDD workflow:

• Tests first = tests are implementation
• No "testing phase" - tests are development
• Feature complete = tests passing
• Can't forget tests - can't write code without them

TDD Workflow Prevents Anti-Patterns

Complete TDD Cycle

// Feature: User registration with email validation

// ========================================
// CYCLE 1: Email validation
// ========================================

// RED: Write failing test
test('rejects invalid email', async () => {
  await expect(registerUser('invalid'))
    .rejects.toThrow('Invalid email');
});
// ❌ Fails - registerUser doesn't exist

// GREEN: Minimal implementation
async function registerUser(email: string) {
  if (!email.includes('@')) {
    throw new Error('Invalid email');
  }
}
// ✅ Passes

// REFACTOR: Improve validation
async function registerUser(email: string) {
  if (!isValidEmail(email)) {  // Better validator
    throw new Error('Invalid email');
  }
}
// ✅ Still passes

// ========================================
// CYCLE 2: Database integration
// ========================================

// RED: Write failing test
test('saves user to database', async () => {
  const user = await registerUser('alice@example.com');
  const saved = await db.users.findById(user.id);
  expect(saved.email).toBe('alice@example.com');
});
// ❌ Fails - no database integration

// GREEN: Add database
async function registerUser(email: string) {
  if (!isValidEmail(email)) {
    throw new Error('Invalid email');
  }
  const user = await db.users.create({ email });  // Added
  return user;
}
// ✅ Passes

// REFACTOR: Extract repository pattern
// Tests still pass

// ========================================
// CYCLE 3: Duplicate prevention
// ========================================

// RED: Write failing test
test('prevents duplicate email', async () => {
  await registerUser('alice@example.com');
  await expect(registerUser('alice@example.com'))
    .rejects.toThrow('Email already exists');
});
// ❌ Fails - no duplicate check

// GREEN: Add check
async function registerUser(email: string) {
  if (!isValidEmail(email)) {
    throw new Error('Invalid email');
  }
  const existing = await db.users.findByEmail(email);
  if (existing) {
    throw new Error('Email already exists');  // Added
  }
  return await db.users.create({ email });
}
// ✅ Passes

// REFACTOR: Improve error handling
// Tests still pass

Notice:

• ✅ No mock behavior testing - real code tested
• ✅ No test-only methods - only what tests needed
• ✅ No uninformed mocking - saw real behavior first
• ✅ No incomplete mocks - used real structures
• ✅ No afterthought tests - tests first always

TDD Mindset: Test-First Thinking

Mental Model

NOT TDD thinking:

"How do I implement this feature?"
  ↓
Implement code
  ↓
"How do I test this?"
  ↓
Write tests
  ↓
Anti-patterns emerge

TDD thinking:

"How will I verify this works?"
  ↓
Write test
  ↓
"What's minimal code to pass?"
  ↓
Implement
  ↓
Anti-patterns prevented

Test-First Benefits

Design benefits:

• API designed from consumer perspective
• Testable code (loose coupling)
• Clear interfaces
• Minimal implementation

Quality benefits:

• Verified behavior
• Edge cases caught early
• Regression prevention
• Living documentation

Anti-pattern prevention:

• Can't test mocks (test fails first against real code)
• No test-only methods (minimal implementation)
• Must understand dependencies (see real behavior)
• Complete structures (test with real data first)
• Tests ARE implementation (not afterthought)

When TDD is Violated

Signs you're not following TDD:

🚩 Writing implementation before test
🚩 Test passes immediately
🚩 Skipping "watch it fail" step
🚩 Mocking before running test
🚩 "Implementation done, adding tests"

Consequences:

• All five anti-patterns become possible
• Test quality degrades
• False confidence
• Design issues

Recovery: 1. Stop adding features 2. Return to TDD workflow 3. Write test first for next feature 4. Watch it fail 5. Minimal implementation 6. Maintain discipline

TDD and Mocking Strategy

TDD-Compliant Mocking

The right way:

// 1. Write test with real implementation
test('user registration sends welcome email', async () => {
  await registerUser('alice@example.com');
  // Observe: Email sending is slow (2 seconds)
});

// 2. Identify slow operation
// emailService.send() is slow (network call)

// 3. Mock at correct level
test('user registration sends welcome email', async () => {
  vi.spyOn(emailService, 'send').mockResolvedValue();

  await registerUser('alice@example.com');

  expect(emailService.send).toHaveBeenCalledWith({
    to: 'alice@example.com',
    subject: 'Welcome'
  });
});
// Test runs fast, verifies email logic

TDD mocking principles:

1. Run with real implementation first - See actual behavior 2. Measure performance - Mock only if slow 3. Mock at boundaries - I/O, network, filesystem 4. Preserve business logic - Don't mock what you're testing 5. Verify behavior, not mocks - Test results, not mock calls

Mocking Levels in TDD

Layer 1: Business Logic
  → NEVER mock (this is what you're testing)

Layer 2: Application Services
  → RARELY mock (needed for assertions)

Layer 3: Adapters
  → SOMETIMES mock (if slow)

Layer 4: External I/O
  → USUALLY mock (network, DB, filesystem)

Layer 5: Infrastructure
  → ALWAYS mock in unit tests (servers, APIs)

Common TDD Mistakes

Mistake 1: Not Watching Test Fail

// ❌ WRONG
test('feature works', () => {
  expect(true).toBe(true);  // Passes immediately
});
// Didn't verify test tests right thing

// ✅ RIGHT
test('validates email', async () => {
  await expect(register('invalid'))
    .rejects.toThrow('Invalid email');
});
// ❌ Fails first - register doesn't exist
// Then implement
// ✅ Passes - verified test works

Mistake 2: Overly Complex Implementation

// ❌ WRONG (not minimal)
test('adds numbers', () => {
  expect(add(2, 3)).toBe(5);
});

function add(a: number, b: number): number {
  // Not minimal - over-engineered
  return Array(b).fill(a).reduce((sum, n) => sum + n, 0);
}

// ✅ RIGHT (minimal)
function add(a: number, b: number): number {
  return a + b;  // Simplest solution
}

Mistake 3: Testing Implementation Details

// ❌ WRONG
test('uses cache', () => {
  const cache = new Cache();
  service.setCache(cache);  // Testing how it works
  expect(service.cache).toBe(cache);
});

// ✅ RIGHT
test('returns cached result', () => {
  service.get('key');
  service.get('key');
  expect(slowOperation).toHaveBeenCalledOnce();  // Testing behavior
});

TDD Discipline

Maintaining TDD Practice

Commit to:

• Test first, always
• Watch it fail, every time
• Minimal implementation, no gold plating
• Refactor with confidence

When tempted to skip TDD:

• "Just a small change" → Write test first
• "I know it works" → Write test to prove it
• "This is hard to test" → Design issue, fix it
• "Tests can wait" → No, they can't

TDD is not optional:

• Not a suggestion
• Not for later
• Not just for new features
• Not "when I have time"

TDD is how you write code.

Integration with Other Skills

Prerequisite skills:

• test-driven-development: Complete TDD workflow (see skill library for full details)

Complementary skills:

• verification-before-completion: Definition of "done" (available in skill library)

Anti-pattern prevention:

• This skill - What TDD prevents

Summary: TDD as Anti-Pattern Prevention

The bottom line: Strict TDD adherence makes testing anti-patterns nearly impossible to create.

If you find yourself with these anti-patterns, you've violated TDD. Return to the RED/GREEN/REFACTOR cycle.

Quick Reference

TDD Cycle:

RED → Write failing test
GREEN → Minimal implementation
REFACTOR → Improve code
REPEAT → Next test

Anti-pattern prevention:

Test first → Prevents afterthought
Watch fail → Prevents mock testing
Minimal code → Prevents test-only methods
Real impl first → Prevents uninformed mocking
Real data first → Prevents incomplete mocks

TDD discipline:

Always test first
Always watch fail
Always minimal implementation
Always refactor
Never skip the cycle

See the Test-Driven Development skill for complete TDD workflow and examples (available in the skill library).