Use when writing or changing tests, adding mocks, or tempted to add test-only methods to production code - prevents testing mock behavior, production pollution with test-only methods, and mocking without understanding dependencies
SkillScore96Maintained
Automatic
◆QA & Test Engineering pack
Last verified 8/2/2026
What it changes
Passed 23 of 24 test cases with the skill, and 16 of 24 without it.
Without skill67%
With skill96%
Checks it passed that the model alone missed
States never test mock behavior
Requires mocking the full API response schema
States never mock without understanding dependencies
and 6 more in the full report
7 fixed16 passed either way1 still failing0 broke
Pass-rate lift
+29 pp
Tokens
+69%
Agent turns
0%
Response time
-45%
Model gemini-3.6-flashMeasured 8/2/2026v123 of 24 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
Before adding a method to a TypeScript production class during development, what two questions must be asked to ensure test pollution does not occur?
What was checked, without and with the skill
Checked
Without skill
With skill
Requires asking if the proposed method is only used by tests
Passed
Passed
Requires asking if the production class owns the resource lifecycle
Missed
Passed
case-08 · gemini-3.6-flash · 8/2/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md315 linessingle file
Testing Anti-Patterns
Overview
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.
The Iron Laws
1. NEVER test mock behavior
2. NEVER add test-only methods to production classes
3. NEVER mock without understanding dependencies
Anti-Pattern 1: Testing Mock Behavior
The violation:
// ❌ BAD: Testing that the mock exists
test('renders sidebar', () => {
render(<Page />);
expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();
});
Why this is wrong:
You're verifying the mock works, not that the component works
Test passes when mock is present, fails when it's not
Tells you nothing about real behavior
your human partner's correction: "Are we testing the behavior of a mock?"