testing-strategy
SKILL.md
Testing Strategy
Systematic test planning and coverage improvement workflow.
When to Use
| Trigger | Description |
|---|---|
| Post-COMPLEX Feature | After implementing major features |
| Coverage Drop | When coverage falls below thresholds |
| Test Debt Sprint | Dedicated testing improvement effort |
| New Project | Establishing testing foundation |
| Pre-Release | Ensuring quality before deployment |
Coverage Targets
| Category | Target | Warning | Critical |
|---|---|---|---|
| Business Logic | >80% | 70-80% | <70% |
| Overall | >60% | 50-60% | <50% |
| Critical Paths | >90% | 80-90% | <80% |
Prerequisites
Before starting:
- Test framework configured
- Coverage tool available
- CI/CD running tests
- Access to current coverage report
- Understanding of business-critical features
Strategy Process
Phase 1: Coverage Analysis
↓
Phase 2: Critical Path Identification
↓
Phase 3: Test Pyramid Planning
↓
Phase 4: Test Prioritization
↓
Phase 5: Edge Case Planning
↓
Phase 6: Flaky Test Remediation
↓
Phase 7: Implementation Roadmap
Phase 1: Coverage Analysis
1.1 Generate Coverage Report
Node.js (Jest/Vitest):
npm test -- --coverage
# or
npx vitest run --coverage
Python (pytest):
pytest --cov=src --cov-report=html
Go:
go test -cover ./...
go test -coverprofile=coverage.out ./...
go tool cover -html=coverage.out
Rust:
cargo tarpaulin --out Html
1.2 Analyze Coverage Gaps
Review coverage report for:
| Area | Target | Current | Gap |
|---|---|---|---|
src/auth/ |
90% | 45% | -45% |
src/api/ |
80% | 62% | -18% |
src/utils/ |
60% | 78% | +18% |
| Overall | 60% | 55% | -5% |
1.3 Identify Uncovered Files
List files with lowest coverage:
Lowest Coverage Files:
1. src/auth/oauth.ts - 12% (critical!)
2. src/api/payments.ts - 28% (critical!)
3. src/services/email.ts - 35%
4. src/utils/validation.ts - 42%
5. src/api/users.ts - 48%
Phase 2: Critical Path Identification
2.1 Define Critical Paths
Critical paths are user journeys that MUST work:
| Path | Description | Files | Priority |
|---|---|---|---|
| Authentication | Login, logout, session | auth/* | P0 |
| Checkout | Cart → Payment → Confirm | payments/, cart/ | P0 |
| Registration | Signup → Verify → Profile | users/, email/ | P1 |
| Search | Query → Results → Filter | search/, api/ | P1 |
2.2 Map Critical Files
For each critical path, list involved files:
Authentication Path:
src/auth/login.ts - 45% coverage
src/auth/session.ts - 52% coverage
src/auth/middleware.ts - 88% coverage
src/models/user.ts - 72% coverage
2.3 Calculate Critical Path Coverage
Authentication Path:
- Total lines: 450
- Covered lines: 267
- Coverage: 59% (target: 90%)
- Gap: 183 lines to cover
Phase 3: Test Pyramid Planning
3.1 Ideal Test Pyramid
/\
/ \
/ E2E \ 10% - Slow, expensive, covers user flows
/______\
/ \
/Integration\ 20% - Medium speed, covers integrations
/______________\
/ \
/ Unit Tests \ 70% - Fast, cheap, covers logic
/____________________\
3.2 Current Distribution
Analyze current test distribution:
Current State:
- Unit tests: 45 (60%)
- Integration: 25 (33%)
- E2E: 5 (7%)
Ideal State:
- Unit tests: 70 (70%)
- Integration: 20 (20%)
- E2E: 10 (10%)
Gap:
- Need +25 unit tests
- Need -5 integration tests (or OK)
- Need +5 E2E tests
3.3 Test Type Guidelines
Unit Tests (70%):
- Pure functions
- Business logic
- Utility functions
- Model methods
- State transitions
Integration Tests (20%):
- API endpoints
- Database operations
- Service interactions
- Authentication flows
- External service mocks
E2E Tests (10%):
- Critical user journeys
- Happy path scenarios
- Cross-system flows
- Smoke tests
Phase 4: Test Prioritization
4.1 Priority Matrix
| Priority | Criteria | Example |
|---|---|---|
| P0 | Critical path, no tests | Payment processing |
| P1 | Critical path, low coverage | Authentication |
| P2 | High risk, medium coverage | Data validation |
| P3 | Medium risk, any coverage | Utility functions |
| P4 | Low risk, nice to have | Formatting helpers |
4.2 Effort Estimation
| Test Type | Effort | Coverage Impact |
|---|---|---|
| Unit (simple) | 15 min | High |
| Unit (complex) | 1 hour | High |
| Integration | 2 hours | Medium |
| E2E | 4 hours | Low (but valuable) |
4.3 Prioritized Test Backlog
## Test Backlog
### P0 - Immediate (This Sprint)
- [ ] Unit: payment.processPayment()
- [ ] Unit: auth.validateToken()
- [ ] Integration: POST /api/payments
- [ ] E2E: Complete checkout flow
### P1 - High (Next Sprint)
- [ ] Unit: auth.refreshToken()
- [ ] Unit: user.validateEmail()
- [ ] Integration: GET /api/users/:id
- [ ] E2E: Registration flow
### P2 - Medium (Backlog)
- [ ] Unit: validation helpers
- [ ] Unit: formatting utilities
- [ ] Integration: Search API
### P3 - Low (Nice to Have)
- [ ] Unit: logging utilities
- [ ] Unit: config loaders
Phase 5: Edge Case Planning
5.1 Required Edge Cases
Every function should test:
| Category | Cases | Example |
|---|---|---|
| Null/Undefined | null, undefined input | validateUser(null) |
| Empty | "", [], {} | searchUsers("") |
| Boundary | 0, -1, MAX_INT | setQuantity(0) |
| Invalid Type | Wrong type input | calculatePrice("abc") |
| Concurrent | Race conditions | Parallel updates |
5.2 Edge Case Checklist
For each function:
- Happy path tested
- Null input tested
- Undefined input tested
- Empty input tested
- Minimum boundary tested
- Maximum boundary tested
- Invalid type tested
- Error conditions tested
Phase 6: Flaky Test Remediation
6.1 Identify Flaky Tests
Signs of flaky tests:
- Intermittent failures in CI
- Tests that pass locally but fail in CI
- Tests that depend on execution order
- Tests with timing-dependent assertions
6.2 Common Causes & Fixes
| Cause | Symptom | Fix |
|---|---|---|
| Timing | Random timeouts | Use proper async/await |
| Order dependency | Fails when run alone | Reset state in beforeEach |
| Shared state | Random failures | Isolate test data |
| External services | Network failures | Mock external calls |
| Date/time | Fails at midnight | Mock dates |
Phase 7: Implementation Roadmap
7.1 Sprint Planning Template
## Sprint 1: Critical Path (2 weeks)
### Goals
- Achieve 90% coverage on authentication
- Achieve 90% coverage on payments
- Add 5 E2E tests for critical paths
### Tasks
1. Unit tests for auth module (20 tests)
2. Unit tests for payment module (15 tests)
3. Integration tests for auth API (5 tests)
4. E2E test: Complete checkout (1 test)
5. E2E test: Login flow (1 test)
### Expected Outcome
- Overall coverage: 55% → 65%
- Critical path coverage: 59% → 90%
7.2 Test Writing Guidelines
Test Structure:
describe('Module or Function', () => {
// Setup
beforeEach(() => {
// Reset state
});
describe('method or scenario', () => {
it('should [expected behavior] when [condition]', () => {
// Arrange
const input = createTestInput();
// Act
const result = functionUnderTest(input);
// Assert
expect(result).toEqual(expectedOutput);
});
});
});
Naming Convention:
should [expected behavior] when [condition]
Examples:
- should return user when valid ID provided
- should throw error when user not found
- should update timestamp when saving
7.3 Coverage Tracking
Track coverage weekly:
| Week | Overall | Business | Critical | Tests Added |
|---|---|---|---|---|
| 1 | 55% | 62% | 59% | +15 |
| 2 | 62% | 75% | 78% | +22 |
| 3 | 68% | 82% | 88% | +18 |
| 4 | 72% | 85% | 92% | +12 |
Quick Reference
Coverage Commands
# Node.js
npm test -- --coverage --coverageReporters=text-summary
# Python
pytest --cov=src --cov-report=term-missing
# Go
go test -cover ./... | grep -E "coverage:"
# Rust
cargo tarpaulin --out Stdout
Test Templates
Unit Test:
describe('functionName', () => {
it('should [behavior] when [condition]', () => {
const result = functionName(input);
expect(result).toEqual(expected);
});
});
Integration Test:
describe('POST /api/resource', () => {
it('should create resource when valid data', async () => {
const response = await request(app)
.post('/api/resource')
.send(validData);
expect(response.status).toBe(201);
});
});
Checklist
Analysis
- Coverage report generated
- Gaps identified
- Critical paths mapped
- Current pyramid analyzed
Planning
- Tests prioritized
- Edge cases documented
- Flaky tests identified
- Sprint plan created
Implementation
- P0 tests written
- P1 tests written
- Edge cases covered
- Flaky tests fixed
Validation
- Coverage targets met
- All tests passing
- No flaky tests
- CI/CD updated
Extended Resources
For detailed examples, patterns, and in-depth guidance, see:
references/process.md- Comprehensive testing patterns and examples
Related Resources
code-review- Includes test validationrefactoring- Tests enable safe refactoringtroubleshooting- When tests fail unexpectedly
Weekly Installs
9
Repository
ar4mirez/samuelGitHub Stars
3
First Seen
Feb 20, 2026
Security Audits
Installed on
opencode9
gemini-cli9
github-copilot9
codex9
amp9
kimi-cli9