Testing selection
Skill ahtishamshahzad/agent_dev_flow/.ai/skills/testing/testing-selection
Tool-neutral AI Engineering System: 174 reusable skills (installable as Claude Code plugins) for planning and building software with AI agents. Classify → plan → approve → build under quality gates. Works with Claude Code, Codex, Cursor, Windsurf, Copilot & Antigravity. Canonical in .ai/.
npx -y skills add ahtishamshahzad/agent_dev_flow --skill testing-selectionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use to choose which test types and tools a project needs — Playwright (web/dashboard E2E), Maestro (mobile E2E/smoke), Supertest (backend API integration), Testing Library (components), Jest/Vitest (unit + integration logic). Selects only what the project's applications and risks justify; does not adopt every tool by default.
SKILL.md
5.4 KB, as published. Nobody here has run it
Testing Selection
Purpose
Decide the test types and tools for the project from its actual applications and risks — the right pyramid per app, and the specific tools that fit — so effort lands where failure hurts. Refines the core ../../testing-strategy for concrete tooling; requires the application/stack decisions as input.
When to Use
- After applications and stack are chosen (
../../application-selection,../../stack-recommendation), when planning how the project is tested. - When adding an application that changes the testing surface.
- Not for writing tests (the per-type skills) or per-bug regression (
regression-testing).
Inputs
- Selected applications (web, dashboard, mobile, backend API) and their risk/criticality.
- Stack per area (drives tool fit) and existing test setup if any (
../../existing-project-audit).
Discovery Questions
- Which applications exist, and what does each break if untested (money, auth, data loss)?
- What is the runtime per app (Node/TS backend, React web, React Native mobile) — which tools are idiomatic?
- Which flows are critical enough to warrant E2E, and which are covered cheaper at lower levels?
- Is there existing test tooling to extend rather than replace?
Responsibilities
- Map each application to its levels + tools, adopting only what's needed:
- Unit + integration logic → Jest or Vitest (one, per stack convention — Vitest for Vite/modern TS, Jest where established); pure logic, services, reducers, hooks.
- Backend API integration → Supertest (real HTTP against the app + real DB) — pairs with
../../backend/backend-integration-testing. - Component/interaction → Testing Library (React / React Native) — accessible queries, user-facing behavior.
- Web/dashboard E2E → Playwright — critical browser flows only.
- Mobile E2E + smoke → Maestro — critical device flows only.
- Contract →
contract-testingwhere independently deployed clients/services must agree.
- Set the pyramid shape per app: many unit, fewer integration, few E2E — E2E is expensive and slow, reserved for critical end-to-end journeys.
- Record what is not adopted and why (no Playwright if there's no web app; no Maestro without mobile) — absence is a decision.
- Feed the choices to
../../devops/ci-cd(jobs are generated from selected apps + selected test types) and to the per-type skills.
Required Workflow
- List applications with risk/criticality.
- Assign levels + tools per app (adopt minimally).
- Fix the pyramid shape and which flows earn E2E.
- Record non-adoptions with reasons.
- Hand off to the per-type skills and
../../devops/ci-cd.
Decision Rules
- One unit/integration runner per stack — not Jest and Vitest in the same app without cause.
- E2E tool follows the platform: Playwright for browsers, Maestro for devices — not one tool stretched across both.
- Supertest is the backend API-integration default (Node); it doesn't replace unit tests or E2E.
- Adopt a tool only when an application needs it; "might need it later" is not now.
- Risk drives depth, not a coverage number (
test-coverage-audit).
Rules
- Selection is recorded and tied to specific applications.
- No tool adopted for an application that doesn't exist.
- The selection drives CI job generation — keep them in sync.
Anti-Patterns
- Adopting the full toolchain on every project reflexively.
- Playwright with no web app; Maestro with no mobile app.
- E2E-heavy pyramids (slow, flaky, expensive) instead of unit-heavy.
- Two unit runners in one app.
- Choosing tools before knowing the applications.
Validation Checklist
- Applications listed with risk.
- Levels + tools assigned per app, minimally.
- Pyramid shape + E2E-worthy flows fixed.
- Non-adoptions recorded with reasons.
- Handed to per-type skills +
../../devops/ci-cd.
Definition of Done
A recorded per-application test-type-and-tool selection — Jest/Vitest, Supertest, Testing Library, Playwright, Maestro adopted only where an application justifies them — with the pyramid shape set and non-adoptions explained, feeding CI generation.
Related Skills
../../testing-strategy, unit-testing, integration-testing, api-integration-testing, contract-testing, playwright-e2e, maestro-e2e, ../../devops/ci-cd, ../../application-selection, ../../stack-recommendation.
Related Knowledge
../../../knowledge/ (application risk, critical flows).
Related References
../../../references/testing/ (tool-fit notes, when populated).
Context Loading Guidance
- Requires: selected applications with risk, stack per area.
- Does not require: test code, the full skill set, unrelated references.
- May load: the per-type skills after selecting,
../../devops/ci-cd. - Stop when: the per-application selection is recorded.
Token Efficiency Guidance
The application × (levels, tools) table is the artifact; decide per app, don't survey every tool for every app.