testing-anti-patterns

Identify and prevent testing anti-patterns in unit, integration, and end-to-end tests.

3|Updated Nov 19, 2025

Search Tags:#testing #development #best practices #anti-patterns #mocks #clean code #test quality

Ready to run

npx skills add https://github.com/seanGSISG/crispy-claude --skill testing-anti-patterns-seangsisg

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: testing-anti-patterns
Source: https://github.com/seanGSISG/crispy-claude/tree/main/.claude/skills/testing-anti-patterns
Command: npx skills add https://github.com/seanGSISG/crispy-claude --skill testing-anti-patterns-seangsisg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Poor testing practices, such as testing mock behavior or polluting production code with test-only methods, lead to brittle tests, false confidence, and maintainability nightmares. This skill identifies and prevents these common pitfalls.

Core Features & Use Cases

Mock Behavior Prevention: Guides against testing mocks instead of real component behavior.
Production Code Purity: Prevents the introduction of test-only methods into production classes.
Smart Mocking: Ensures mocks are used judiciously and with full understanding of dependencies, avoiding incomplete or misleading test setups.

Quick Start

Use the testing-anti-patterns skill to review my current test suite for common mistakes, especially around mocking.

Frequently Asked Questions about testing-anti-patterns

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

FAQPage Schema

How do I identify testing anti-patterns in my test suite?▼

Testing anti-patterns include verifying mock behavior instead of real component logic, adding test-only methods to production code, and over-mocking without understanding dependencies. Review your unit, integration, and end-to-end tests against these three core violations to catch brittle tests early.

Why shouldn't I test mock behavior?▼

Testing mock behavior creates false confidence—you're validating the mock's configuration, not your actual code. This iron law prevents brittle tests that pass despite production failures. Always test real component behavior and dependencies instead.

What's the difference between smart mocking and over-mocking?▼

Smart mocking uses mocks with complete, realistic data structures after understanding your actual dependencies. Over-mocking adds unnecessary mocks with incomplete setups, making tests misleading and harder to maintain. Gate every mock decision against genuine dependency needs.

How do I avoid polluting production code with test-only methods?▼

Test-only methods violate the separation of concerns and complicate production logic. Before adding any test-specific code or gate functions, confirm the dependency truly requires it. This iron law keeps production classes focused and maintainable.

Can I use anti-pattern prevention across unit, integration, and end-to-end tests?▼

Yes. The three iron laws—never test mock behavior, never add test-only production methods, never mock without understanding dependencies—apply consistently across unit, integration, and end-to-end tests in production-like environments for uniform test quality.

What are the consequences of brittle tests and false confidence?▼

Brittle tests fail unpredictably during refactoring despite correct logic, and false confidence from mock-behavior testing masks real production bugs. Poor testing practices create maintainability nightmares and erode code reliability over time.