Testing Strategy
Design a balanced test strategy and written test plan with pyramid levels, coverage targets, and example cases before or while shipping features.
Overview
testing-strategy is an agent skill most often used in Ship (also Build backend/frontend) that designs test plans balancing pyramid layers, coverage, and maintenance.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill testing-strategyWhat is this skill?
- Testing pyramid guidance: many unit, some integration, few E2E
- Component-type playbooks for API, data pipelines, frontend, and infrastructure
- Focus matrix: critical paths, errors, edges, security boundaries, data integrity
- Explicit skip guidance for trivial getters, framework boilerplate, one-off scripts
- Deliverable: typed coverage plan plus gap analysis against existing tests
- 3-layer testing pyramid (unit, integration, E2E)
- 4 component strategy buckets: API, pipelines, frontend, infrastructure
Adoption & trust: 3.4k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need tests for a feature but lack a plan—so you either skip testing or chase slow E2E that still miss critical logic.
Who is it for?
Indie SaaS and API builders pre-launch or post-refactor who want agent-guided architecture before writing test files.
Skip if: Executing tests in CI, writing production code without any component to test, or formal compliance audit checklists.
When should I use this skill?
User asks how should we test, test strategy for, write tests for, test plan, what tests do we need, or needs coverage and test architecture help.
What do I get? / Deliverables
You get a structured test plan with layer choices, targets, example cases, and documented coverage gaps ready for implementation in your repo.
- Test plan with per-area test types
- Coverage targets and example cases
- Gap list for uncovered critical paths
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill outputs test architecture and plans aimed at release confidence, not initial product discovery. Testing subphase matches explicit triggers around how to test, test plans, and coverage gaps.
Where it fits
Define unit vs integration split for a new REST module before your agent generates pytest files.
Choose component vs interaction vs a11y coverage for a dashboard refactor.
Produce a pre-release test plan highlighting critical paths and security boundaries.
Revisit pyramid balance after outages to add smoke or chaos tests called out for infrastructure.
How it compares
Use as a planning layer before codegen test skills—it defines strategy and gaps, not the full test implementation run.
Common Questions / FAQ
Who is testing-strategy for?
Solo developers and tiny teams shipping web apps, APIs, or data features who want agent help on what to test and how.
When should I use testing-strategy?
When you ask how should we test, test strategy for, write tests for, test plan, or what tests do we need; during ship testing before release; during build when adding a new service or UI surface.
Is testing-strategy safe to install?
It is documentation-only strategy guidance with no embedded tool calls; review the Security Audits panel on this page for the package source.
SKILL.md
READMESKILL.md - Testing Strategy
# Testing Strategy Design effective testing strategies balancing coverage, speed, and maintenance. ## Testing Pyramid ``` / E2E \ Few, slow, high confidence / Integration \ Some, medium speed / Unit Tests \ Many, fast, focused ``` ## Strategy by Component Type - **API endpoints**: Unit tests for business logic, integration tests for HTTP layer, contract tests for consumers - **Data pipelines**: Input validation, transformation correctness, idempotency tests - **Frontend**: Component tests, interaction tests, visual regression, accessibility - **Infrastructure**: Smoke tests, chaos engineering, load tests ## What to Cover Focus on: business-critical paths, error handling, edge cases, security boundaries, data integrity. Skip: trivial getters/setters, framework code, one-off scripts. ## Output Produce a test plan with: what to test, test type for each area, coverage targets, and example test cases. Identify gaps in existing coverage.