Question 1

How do I stop testing mock behavior instead of real component logic?

Accepted Answer

Testing mock behavior verifies the mock exists, not your actual code. Instead, test the real component's output and side effects. For example, assert on rendered DOM or function return values, not on whether a mock was called. This ensures tests catch real bugs.

Question 2

Why are my tests flaky and how do I fix them?

Accepted Answer

Flaky tests often result from over-mocking, testing mock interactions, or incomplete mock API structures. Eliminate tests that only verify mock existence, ensure mocks mirror full dependency APIs, and mock only external side effects. This stabilizes your test suite and increases confidence.

Question 3

Can I add helper methods to production code for testing?

Accepted Answer

No. Test-only production methods pollute your codebase and hide real behavior from tests. Instead, refactor production code to expose necessary behavior through public APIs, or adjust your test approach to work with existing interfaces. Keep production and test concerns separate.

Question 4

When should I mock dependencies in JavaScript/TypeScript tests?

Accepted Answer

Mock external dependencies—APIs, databases, file systems—whose behavior you cannot control in tests. Do not mock internal application logic or components under test. Understand each dependency's API fully before mocking to avoid incomplete stubs that hide bugs in real interactions.

Question 5

How do I refactor an existing test suite to remove anti-patterns?

Accepted Answer

Audit tests for mock-behavior assertions and test-only production code. Replace mock assertions with real component behavior checks. Restore full dependency API structures in mocks. Test side effects and outputs, not mock calls. Verify each test validates meaningful application functionality.

Question 6

What's the difference between unit and integration tests in mocking strategy?

Accepted Answer

Unit tests isolate a single component and mock its external dependencies. Integration tests verify components work together with minimal mocking. Both enforce the same rule: never test mock behavior. Mock only genuine external boundaries; test actual interactions between your code and those boundaries.

testing-anti-patterns

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Core Features & Use Cases

Quick Start

The Iron Laws:

1. NEVER test mock behavior

2. NEVER add test-only methods to production classes

3. NEVER mock without understanding dependencies

Example: Testing mock behavior (❌ BAD)

test('renders sidebar', () => {

render(<Page />);

expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();

});

Frequently Asked Questions about testing-anti-patterns

Related Skills

unit-testing

test-driven-development

testing

api-testing