Testing Procedures
Systematic testing skill covering strategy, patterns, and quality gates. Produces consistent, maintainable test suites across tech stacks.
When to Use
- Writing new tests for features or bug fixes
- Designing test strategy for a new project or module
- Evaluating existing test coverage and quality
- Setting up test infrastructure (fixtures, factories, mocks)
- Creating or updating
TESTING.md documentation
When NOT to Use
- Running tests (use
run-tests skill workflow instead)
- Reviewing test code quality (use
code-review skill)
- Validating CI pipeline configuration (use
devops-engineer role)
Test Pyramid
Follow the test pyramid for cost-effective coverage:
/ E2E \ Few — critical user journeys only
/----------\
/ Integration \ Moderate — API, DB, service boundaries
/----------------\
/ Unit Tests \ Many — fast, isolated, comprehensive
/--------------------\
| Layer |
What to Test |
Speed |
Count |
| Unit |
Pure logic, transformations, validators, utils |
< 50ms |
Many |
| Integration |
DB queries, API endpoints, service interactions |
< 5s |
Moderate |
| E2E |
Critical user journeys, happy paths, key flows |
< 30s |
Few |
Test Design Principles
- Test behavior, not implementation — assert outcomes, not internal calls
- One assertion per concept — each test verifies one logical thing
- Arrange-Act-Assert — clear structure in every test
- Deterministic — no flaky tests. Mock time, randomness, external services
- Independent — tests must not depend on execution order
- Descriptive names — test name describes the scenario:
should_return_404_when_user_not_found
- Fast feedback — unit tests run in seconds, not minutes
Coverage Targets
| Metric |
Target |
Hard Minimum |
| Line coverage |
≥ 80% |
≥ 60% |
| Branch coverage |
≥ 75% |
≥ 50% |
| Critical path coverage |
100% |
100% |
| New code coverage |
≥ 90% |
≥ 80% |
Critical paths = authentication, authorization, payment, data mutations, error handling.
Key Context File
Projects should have a TESTING.md at the root (and per-service in monorepos) documenting test infrastructure, commands, credentials, and organization. Created by project-init skill using qa-engineer role. Always read TESTING.md before writing or running tests.
Integration
- Follows rules:
qa-engineer role (test strategy, automation, local test infra), software-engineer role (code quality)
- Used by workflows:
test-local skill (full local QA cycle), run-tests skill (lightweight execution), project-init skill (TESTING.md generation), feature-dev skill, bugfix skill, pre-commit skill
- Companion resources:
test-writing-guide.md
- Template:
templates/testing.template.md (root + per-service TESTING.md templates)
- Project context:
TESTING.md (root + per-service)
1---2name: test-strategy-23description: Test strategy design, test writing guide, and coverage targets. Use when writing tests, designing test plans, setting up test infrastructure, or evaluating test quality. Provides patterns for unit, integration, E2E, and API testing.4---56# Testing Procedures78Systematic testing skill covering strategy, patterns, and quality gates. Produces consistent, maintainable test suites across tech stacks.910## When to Use1112- Writing new tests for features or bug fixes13- Designing test strategy for a new project or module14- Evaluating existing test coverage and quality15- Setting up test infrastructure (fixtures, factories, mocks)16- Creating or updating `TESTING.md` documentation1718## When NOT to Use1920- Running tests (use `run-tests` skill workflow instead)21- Reviewing test code quality (use `code-review` skill)22- Validating CI pipeline configuration (use `devops-engineer` role)2324## Test Pyramid2526Follow the test pyramid for cost-effective coverage:2728```29 / E2E \ Few — critical user journeys only30 /----------\31 / Integration \ Moderate — API, DB, service boundaries32 /----------------\33 / Unit Tests \ Many — fast, isolated, comprehensive34 /--------------------\35```3637| Layer | What to Test | Speed | Count |38|---|---|---|---|39| **Unit** | Pure logic, transformations, validators, utils | < 50ms | Many |40| **Integration** | DB queries, API endpoints, service interactions | < 5s | Moderate |41| **E2E** | Critical user journeys, happy paths, key flows | < 30s | Few |4243## Test Design Principles44451. **Test behavior, not implementation** — assert outcomes, not internal calls462. **One assertion per concept** — each test verifies one logical thing473. **Arrange-Act-Assert** — clear structure in every test484. **Deterministic** — no flaky tests. Mock time, randomness, external services495. **Independent** — tests must not depend on execution order506. **Descriptive names** — test name describes the scenario: `should_return_404_when_user_not_found`517. **Fast feedback** — unit tests run in seconds, not minutes5253## Coverage Targets5455| Metric | Target | Hard Minimum |56|---|---|---|57| Line coverage | ≥ 80% | ≥ 60% |58| Branch coverage | ≥ 75% | ≥ 50% |59| Critical path coverage | 100% | 100% |60| New code coverage | ≥ 90% | ≥ 80% |6162**Critical paths** = authentication, authorization, payment, data mutations, error handling.6364## Key Context File6566Projects should have a `TESTING.md` at the root (and per-service in monorepos) documenting test infrastructure, commands, credentials, and organization. Created by `project-init` skill using `qa-engineer` role. Always read `TESTING.md` before writing or running tests.6768## Integration6970- **Follows rules**: `qa-engineer` role (test strategy, automation, local test infra), `software-engineer` role (code quality)71- **Used by workflows**: `test-local` skill (full local QA cycle), `run-tests` skill (lightweight execution), `project-init` skill (TESTING.md generation), `feature-dev` skill, `bugfix` skill, `pre-commit` skill72- **Companion resources**: `test-writing-guide.md`73- **Template**: `templates/testing.template.md` (root + per-service TESTING.md templates)74- **Project context**: `TESTING.md` (root + per-service)
avav25