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
SkillScore100Maintained
Automatic
◆QA & Test Engineering pack
Last verified 8/21/2026
What it changes
Passed 23 of 23 test cases with the skill, and 19 of 23 without it.
Without skill83%
With skill100%
Checks it passed that the model alone missed
Recommends moving the cleanup logic into a dedicated test utility module
States that if the method is exclusively for test teardown, it must be placed in test utilities
Explains that post-hoc testing increases the risk of writing tests that merely mirror mock behavior
and 1 more in the full report
4 fixed19 passed either way0 still failing0 broke
Pass-rate lift
+17 pp
Tokens
+89%
Agent turns
0%
Response time
-34%
Model gemini-3.6-flashMeasured 8/21/2026v123 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
A developer wants to know if adding a `disconnectWebSocket()` method to a production `ChatRoom` component is acceptable if it is currently only called in `afterEach()` test cleanup hooks. What criterion determines whether `disconnectWebSocket()` belongs in `ChatRoom`?
What was checked, without and with the skill
Checked
Without skill
With skill
States that if ChatRoom owns the WebSocket lifecycle in production, the method belongs on ChatRoom
Passed
Passed
States that if the method is exclusively for test teardown, it must be placed in test utilities
Missed
Passed
case-19 · gemini-3.6-flash · 8/21/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md297 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?"
The fix:
// ✅ GOOD: Test real component or don't mock it
test('renders sidebar', () => {