comprehensive-testing
This Claude Code skill provides a comprehensive testing strategy framework covering test-driven development workflows, the test pyramid structure, and best practices for unit, integration, and end-to-end testing across frameworks like Jest, Vitest, and pytest. Use it when writing test suites, reviewing test quality standards, establishing testing protocols, or guiding implementation through test-first development processes.
git clone --depth 1 https://github.com/majiayu000/spellbook /tmp/comprehensive-testing && cp -r /tmp/comprehensive-testing/skills/comprehensive-testing ~/.claude/skills/comprehensive-testingSKILL.md
# Comprehensive Testing
> Based on [Anthropic's Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) and community patterns
## Core Philosophy
> "Claude performs best when it has a clear target to iterate against—a test case provides concrete success criteria."
Testing is not about proving code works; it's about **designing code that is testable** and **documenting expected behavior**.
---
## Test Pyramid
```
/\
/ \ E2E Tests (10%)
/----\ - Full user flows
/ \ - Slowest, most brittle
/--------\
/ \ Integration Tests (20%)
/------------\ - Component interaction
/ \ - Real dependencies
/----------------\
Unit Tests (70%)
- Single function/method
- Fast, isolated, many
```
| Level | Speed | Scope | When to Use |
|-------|-------|-------|-------------|
| Unit | <10ms | Single function | All logic |
| Integration | <1s | Multiple components | APIs, DB |
| E2E | <30s | Full flow | Critical paths |
---
## TDD Workflow (Anthropic Recommended)
### The 6-Step Process
```
1. WRITE TESTS FIRST
↓
2. VERIFY TESTS FAIL
↓
3. COMMIT TEST SUITE
↓
4. IMPLEMENT CODE
↓
5. VERIFY WITH SUBAGENT
↓
6. COMMIT IMPLEMENTATION
```
### Step 1: Write Tests First
```markdown
Be EXPLICIT about TDD to avoid mock implementations:
"I want to implement [feature] using TDD.
First, write tests for [expected behavior] with these input/output pairs:
- Input: X → Expected: Y
- Input: A → Expected: B
Do NOT create any implementation yet."
```
### Step 2: Verify Tests Fail
```bash
# Run tests and confirm they fail for the RIGHT reason
npm test # or pytest, go test, etc.
# Expected: "function not found" or "undefined"
# NOT: syntax error, wrong import
```
### Step 3: Commit Test Suite
```bash
git add tests/
git commit -m "test: Add tests for [feature] (RED phase)"
```
### Step 4: Implement Incrementally
```markdown
"Now implement the code to make these tests pass.
Do NOT modify the tests.
Run tests after each change until all pass."
```
Claude will enter an autonomous loop:
```
Write code → Run tests → Analyze failures → Adjust → Repeat
```
### Step 5: Verify with Subagent
```markdown
"Use a subagent to independently verify the implementation:
- Is it overfitting to tests?
- Are edge cases handled?
- Is the code maintainable?"
```
### Step 6: Commit Implementation
```bash
git add src/
git commit -m "feat: Implement [feature] (GREEN phase)"
```
---
## Test Structure Patterns
### AAA Pattern (Arrange-Act-Assert)
```typescript
describe('UserService', () => {
it('should create user with valid email', async () => {
// Arrange - Setup test data and dependencies
const userRepo = new InMemoryUserRepository();
const service = new UserService(userRepo);
const input = { email: 'test@example.com', name: 'Test' };
// Act - Execute the code under test
const user = await service.create(input);
// Assert - Verify the results
expect(user.email).toBe('test@example.com');
expect(user.id).toBeDefined();
expect(await userRepo.findById(user.id)).toEqual(user);
});
});
```
### Given-When-Then Pattern
```python
def test_order_total_with_discount():
"""
Given an order with items totaling $100
When a 20% discount is applied
Then the total should be $80
"""
# Given
order = Order()
order.add_item(Item(price=50))
order.add_item(Item(price=50))
# When
order.apply_discount(Percentage(20))
# Then
assert order.total == Money(80)
```
---
## Framework Best Practices
### Jest / Vitest (JavaScript/TypeScript)
```typescript
// Structure
describe('ModuleName', () => {
describe('methodName', () => {
it('should [expected behavior] when [condition]', () => {});
});
});
// Setup/Teardown
beforeAll(async () => { /* one-time setup */ });
beforeEach(() => { /* per-test setup */ });
afterEach(() => { /* per-test cleanup */ });
afterAll(async () => { /* one-time cleanup */ });
// Async testing
it('handles async operations', async () => {
const result = await asyncFunction();
expect(result).toBe(expected);
});
// Error testing
it('throws on invalid input', () => {
expect(() => validate(null)).toThrow('Input required');
});
// Snapshot testing (use sparingly)
it('renders correctly', () => {
const tree = renderer.create(<Component />).toJSON();
expect(tree).toMatchSnapshot();
});
// Table-driven tests
it.each([
[1, 1, 2],
[2, 2, 4],
[0, 0, 0],
])('add(%i, %i) = %i', (a, b, expected) => {
expect(add(a, b)).toBe(expected);
});
```
**vitest.config.ts:**
```typescript
export default defineConfig({
test: {
globals: true,
environment: 'node',
coverage: {
provider: 'v8',
reporter: ['text', 'json', 'html'],
thresholds: {
lines: 80,
branches: 70,
functions: 80,
},
},
},
});
```
### pytest (Python)
```python
import pytest
from mymodule import Calculator
# Fixtures for dependency injection
@pytest.fixture
def calculator():
return Calculator()
@pytest.fixture
def database():
db = TestDatabase()
yield db
db.cleanup()
# Parametrized tests
@pytest.mark.parametrize("a,b,expected", [
(1, 1, 2),
(2, 2, 4),
(0, 0, 0),
(-1, 1, 0),
])
def test_add(calculator, a, b, expected):
assert calculator.add(a, b) == expected
# Exception testing
def test_divide_by_zero(calculator):
with pytest.raises(ZeroDivisionError):
calculator.divide(1, 0)
# Async testing
@pytest.mark.asyncio
async def test_async_operation():
result = await async_function()
assert result == expected
# Markers for categorization
@pytest.mark.slow
@pytest.mark.integration
def test_database_connection(database):
assert database.is_connected()
```
**conftest.py:**
```python
import pytest
@pytest.fixture(scope="session")
def database_url():
return "postgresql://test:test@localhosAudit AND optimize a CLAUDE.md / AGENTS.md instruction file — score it against the five high-leverage patterns, flag anti-patterns, then apply approved fixes in place. Use when the user says 优化 CLAUDE.md / 优化 AGENTS.md / optimize my agent doc / 帮我改 claudemd, or after an audit when they want the fixes applied (not just reported).
Generate or update repository-specific AGENTS.md instruction files from real repo evidence. Use when asked to create, design, scaffold, split, or improve root or scoped AGENTS.md files for Codex/Claude/agent workflows, especially when a repo needs directory-specific rules, validation commands, generated-file boundaries, or a short agent onboarding router.
REST/GraphQL/gRPC API design best practices. Use when designing APIs, defining contracts, handling versioning. Covers OpenAPI 3.2, GraphQL Federation, gRPC streaming.
Mobile app UI design expert for iOS and Android. Use when designing app interfaces, creating design systems, ensuring accessibility, or following platform guidelines. Covers Material Design 3, Human Interface Guidelines, color theory, typography, and 2025 trends.
End-to-end app feature inventory and user-story testing workflow with a canonical tracker. Use when the user asks to audit every feature, derive expected behavior from code, test user journeys, or explicitly fix and retest documented UX or logistical defects.
Design architecture foundations before implementation. Use when asked to design or refactor architecture, choose Rust/Go crate, package, module, runtime, workflow, or service boundaries, compare mature project architecture, prevent stacked one-off PRs, audit migration debt in existing repos, or produce a spec before coding.
Evidence-driven architecture research for understanding real systems and making technical decisions. Use when doing architecture landscape studies, source-backed system archaeology, build-vs-buy or adopt/adapt/build decisions, open-source and commercial comparisons, revisiting an earlier architecture choice, or handling requests such as 架构调研, 架构选型, 竞品架构, 技术尽调, 同类方案, 开源替代, how is X built, and what should we learn from X. Do not use for small mechanical changes, market-only discovery, or detailed design after the technology direction is already fixed.
Ask Grok or Gemini via opencli (browser-session based, no API cost). Use when the user says "问 grok", "问 gemini", "ask grok", "ask gemini", "用 grok 查", "grok 怎么看", "让 gemini 分析", or wants a second opinion from Grok/Gemini without paying API tokens. Routes to opencli which drives the already-logged-in Chrome session.