Testing Anti-Patterns

Detects and corrects common mocking and test-design anti-patterns in test suites.

Updated Dec 4, 2025
One-click install
npx skills add https://github.com/dallascrilley/dowser --skill testing-anti-patterns-dallascrilley
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: Testing Anti-Patterns
Source: https://github.com/dallascrilley/dowser/tree/main/skills/testing-anti-patterns
Command: npx skills add https://github.com/dallascrilley/dowser --skill testing-anti-patterns-dallascrilley

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Tests often verify mock behavior instead of real behavior, pollute production classes with test-only methods, or mock dependencies without understanding their side effects, producing suites that pass for the wrong reasons and fail mysteriously. ## Core Features & Use Cases - Mock Behavior Detection: Identifies assertions that verify mock existence rather than real component behavior, with gate functions to run before asserting on mock elements. - Production Code Protection: Prevents test-only methods like cleanup destroy() calls from leaking into production classes by moving them to test utilities. - Dependency-Aware Mocking: Enforces understanding of side effects before mocking, complete mock structures mirroring real API responses, and minimal mocking at the correct level. - Use Case: While writing a test that mocks a service layer, the gate functions prompt you to check whether the test depends on the mocked method's side effects, so you mock the slow external call instead of the high-level method the test relies on. ## Quick Start Review my test file for mock-related anti-patterns and suggest fixes before I commit it.

Frequently Asked Questions about Testing Anti-Patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I avoid testing mock behavior instead of real behavior?▼

Before asserting on any mock element, ask whether you are testing real component behavior or just mock existence. Either unmock the component and assert on real output, or keep the mock only for isolation and assert on the behavior of the code under test.

Should test cleanup methods live in production classes?▼

No. Methods used only by tests, such as a destroy() called in afterEach, belong in test utility modules, not production classes. This keeps production APIs clean and avoids dangerous lifecycle methods being called in real deployments.

Why does my test pass but fail in integration?▼

A common cause is incomplete mocks that omit fields downstream code depends on, or mocking a high-level method whose side effects the test relies on. Mirror the complete real API response structure and mock at the lowest level that isolates the slow or external operation.

When should I use integration tests instead of mocks?▼

Consider integration tests when mock setup exceeds the test logic, when you are mocking everything to make the test pass, or when mocks drift from the real component's interface. Real components are often simpler than maintaining complex mock hierarchies.

How does TDD prevent mocking anti-patterns?▼

Writing the failing test first forces you to define what real behavior you are verifying before introducing mocks. Watching the test fail against real code reveals actual dependencies, so mocks are added minimally and at the correct level afterward.