comprehensive-testing
Complete testing strategy covering TDD workflow, test pyramid, unit/integration/E2E/property testing, framework best practices (Jest, Vitest, pytest), mock strategies, and CI integration. Use when writing tests, reviewing test quality, or establishing testing standards.
What this skill does
# 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: '[email protected]', name: 'Test' };
// Act - Execute the code under test
const user = await service.create(input);
// Assert - Verify the results
expect(user.email).toBe('[email protected]');
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@localhost/test"
@pytest.fixture(autouse=True)
def reset_database(database):
yield
database.rollback()
```
**pytest.ini:**
```ini
[pytest]
testpaths = tests
python_files = test_*.py
python_functions = test_*
addopts = -v --cov=src --cov-report=term-missing
markers =
slow: marks tests as slow
integration: marks tests as integration tests
```
### Go Testing
```go
package mypackage
import (
"testing"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestAdd(t *testing.T) {
tests := []struct {
name string
a, b int
expected int
}{
{"positive numbers", 1, 2, 3},
{"zero values", 0, 0, 0},
{"negative numbers", -1, -2, -3},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
result := Add(tt.a, tt.b)
assert.Equal(t, tt.expected, result)
})
}
}
// Table-driven with subtests
func TestUserService_Create(t *testing.T) {
t.Run("creates user with valid input", func(t *testing.T) {
repo := NewInMemoryRepo()
svc := NewUserService(repo)
user, err := svc.Create(CreateUserInput{Email: "[email protected]"})
require.NoError(t, err)
assert.NotEmpty(t, user.ID)
assert.Equal(t, "[email protected]", user.Email)
})
t.Run("returns error for invalid email", func(t *testing.T) {
repo := NewInMemoryRepo()
svc := NewUserService(repo)
_, err := svc.Create(CreateUserInput{Email: "invalid"})
require.Error(t, err)
assert.Contains(t, err.Error(), "invalid email")
})
}
```
---
## Mock Strategy
### When to Mock
| Scenario | Mock? | Reason |
|----------|-------|--------|
| External APIs | ✅ Yes | Slow, unreliable, costs money |
| Time/Date | ✅ Yes | Non-deterministic |
| Random | ✅ Yes | Non-deterministic |
| Database (unit) | ✅ Yes | Slow, complex setup |
| Database (integration) | ❌ No | Test real behavior |
|Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.