Test quality guard - prevents testing mock behavior, production pollution with test-only methods, and mocking without understanding dependencies.
Detects and prevents common testing anti-patterns like verifying mock behavior or polluting production code.
npx claudepluginhub lerianstudio/ringThis skill inherits all available tools. When active, it can use any tool Claude has access to.
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.
1. NEVER test mock behavior
2. NEVER add test-only methods to production classes
3. NEVER mock without understanding dependencies
BAD: expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument() - testing mock exists, not real behavior.
GOOD: expect(screen.getByRole('navigation')).toBeInTheDocument() - test real component or don't mock.
Gate: Before asserting on mock element → "Am I testing real behavior or mock existence?" If mock → delete assertion or unmock.
BAD: session.destroy() method only used in tests - pollutes production, dangerous if called.
GOOD: cleanupSession(session) in test-utils/ - keeps production clean.
Gate: "Is this method only used by tests?" → Put in test utilities. "Does this class own this lifecycle?" → If no, wrong class.
BAD: Mocking discoverAndCacheTools breaks config write test depends on - test passes for wrong reason.
GOOD: Mock only the slow part (MCPServerManager), preserve behavior test needs.
Gate: Before mocking → (1) What side effects does real method have? (2) Does test depend on them? If yes → mock at lower level. Red flags: "Mock to be safe", "might be slow", mocking without understanding.
BAD: Partial mock missing metadata field - breaks when downstream code accesses response.metadata.requestId.
GOOD: Complete mock mirroring real API - ALL fields real API returns.
Iron Rule: Mock COMPLETE data structure, not just fields your test uses. Partial mocks fail silently.
Gate: Before mock → Check real API response, include ALL fields. If uncertain → include all documented fields.
BAD: "Implementation complete" without tests. FIX: TDD cycle: write test → implement → refactor → claim complete.
Warning signs: Mock setup longer than test logic, mocking everything, mocks missing methods real components have. Consider: Integration tests with real components often simpler than complex mocks.
TDD forces: (1) Think about what you're testing, (2) Watch fail confirms real behavior not mocks, (3) See what test needs before mocking. If testing mock behavior, you violated TDD.
| Anti-Pattern | Fix |
|---|---|
| Assert on mock elements | Test real component or unmock it |
| Test-only methods in production | Move to test utilities |
| Mock without understanding | Understand dependencies first, mock minimally |
| Incomplete mocks | Mirror real API completely |
| Tests as afterthought | TDD - tests first |
| Over-complex mocks | Consider integration tests |
*-mock test IDsMocks are tools to isolate, not things to test.
If TDD reveals you're testing mock behavior, you've gone wrong.
Fix: Test real behavior or question why you're mocking at all.
STOP and report if:
| Decision Type | Blocker Condition | Required Action |
|---|---|---|
| Mock Justification | Cannot explain what real behavior the mock enables testing | STOP and report |
| Test-Only Method | Method exists only for test purposes in production code | STOP and report |
| Incomplete Mock | Mock missing fields that real API returns | STOP and report |
| TDD Violation | Tests written after implementation complete | STOP and report |
The following requirements CANNOT be waived:
| Severity | Condition | Required Action |
|---|---|---|
| CRITICAL | Asserting on mock elements (*-mock test IDs) | MUST fix immediately |
| CRITICAL | Test-only methods in production classes | MUST fix immediately |
| HIGH | Mocking without understanding side effects | MUST fix before completing |
| HIGH | Incomplete mocks missing required fields | MUST fix before completing |
| MEDIUM | Mock setup exceeds 50% of test logic | Should fix |
| LOW | Test coverage gaps in non-critical paths | Fix in next iteration |
| User Says | Your Response |
|---|---|
| "Just mock it to make the test pass quickly" | "CANNOT mock without understanding what behavior I'm enabling tests for. Let me analyze the real dependencies first." |
| "Add a test-only method, it's the fastest solution" | "CANNOT add test-only methods to production code. I'll create a test utility instead." |
| "The mock doesn't need all those fields" | "CANNOT use incomplete mocks. Partial mocks fail silently when downstream code accesses missing fields." |
| "Skip TDD, we're behind schedule" | "CANNOT skip TDD. Writing tests after leads to testing mock behavior instead of real behavior." |
| Rationalization | Why It's WRONG | Required Action |
|---|---|---|
| "Mock makes the test simpler" | Simpler test ≠ correct test. You may be testing mock existence, not behavior. | MUST verify assertion tests real behavior |
| "Test-only method is small, doesn't hurt" | Any test pollution in production is dangerous if called accidentally. | MUST move to test utilities |
| "I know what the mock needs" | Assumption ≠ verification. Check real API response. | MUST verify mock completeness against real API |
| "Tests after is the same as TDD" | Order matters. TDD reveals what to mock; tests-after tests mocks blindly. | MUST follow RED-GREEN-REFACTOR |
| "Mocking to be safe" | "Safe" mocking without understanding breaks tests that depend on real behavior. | MUST understand dependencies before mocking |
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.