testing-anti-patterns

Testing mock behavior—asserting that mocks exist or were called—creates false confidence without verifying actual functionality. Instead, assert on real component output or behavior, or test how your code handles the mock's expected interactions, ensuring tests validate genuine code paths.

Test-only production methods pollute your codebase, create maintenance burden, and expose internal implementation details. Keep tests isolated from production by using mocks at appropriate boundaries or refactoring to make real behavior testable without special hooks.

Mock external dependencies—APIs, databases, file systems—to isolate the code under test. Mock at boundaries where your code interacts with services outside its control, but verify your code's real behavior when handling the mock's output, not the mock interaction itself.

Testing mock interactions checks if a mock was called; testing real behavior verifies your code produces correct output or side effects. Real behavior testing catches actual bugs; mock-only tests pass even when production code fails, masking regressions.

Integration tests exercise real components together, mocking only external systems your code doesn't control. Test the Page component with a real Sidebar by checking actual DOM output, not mock presence—this catches real integration failures unit tests miss.

Common anti-patterns include asserting on mock existence, adding test helper methods to production, mocking internal dependencies, and writing tests that pass but don't verify real behavior. These mask bugs and create brittle, misleading test suites that give false confidence.