agentsclimarketplace

Testing strategy

Skill ahtishamshahzad/agent_dev_flow/.ai/skills/testing-strategy

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/.

Install
npx -y skills add ahtishamshahzad/agent_dev_flow --skill testing-strategy

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 22 days oldThe repository was created 22 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 testing levels and tools per application and change, proportional to risk, and to define what "tested" means for the work. Aligns with the approved stack; every bug fix gets a regression test. Honest about what was actually run.

SKILL.md

3.7 KB, 779 tokens by cl100k_base, as published. Nobody here has run it

Testing Strategy

Purpose

Decide the testing levels and tools for a piece of work, sized to risk, and define the coverage that satisfies Gate 5. Implements ../../system/TESTING_SELECTION_RULES.md.

When to Use

  • When planning a feature/bug/refactor/migration that needs tests.
  • For a testing audit request type (assess existing coverage).
  • Not to mandate blanket coverage regardless of risk.

Inputs

  • The change and its risk profile.
  • Approved stack (test tooling must align).
  • Existing test setup (existing-project-audit).

Discovery Questions

  • What is the risk level (auth/payments/data vs low-risk pure functions)?
  • Which application(s) and levels are involved (unit/integration/E2E/contract)?
  • What tooling already exists to align with?
  • What is the critical path to cover first?

Responsibilities

  • Choose levels: unit · integration · E2E · contract · regression.
  • Choose tools per application (Jest · Vitest · Supertest · Playwright · Maestro · RNTL), aligned to the stack.
  • Prioritize the critical path; record deferred coverage.
  • Ensure every bug fix has a regression test.
  • Define what "tested" means for the work (the Gate 5 bar).

Required Workflow

  1. Assess risk and affected applications.
  2. Select levels matched to risk.
  3. Select tools matched to each application and the stack.
  4. Define required coverage + critical path.
  5. Note what will actually be run vs "unverified until run."

Decision Rules

  • Match level to risk: auth/payments/data integrity → integration + E2E, not just units.
  • Match tool to app: web → Playwright; mobile → Maestro; API → Supertest; RN components → RNTL.
  • Every bug → a regression test.
  • Test behavior and contracts, not churn-prone implementation detail.

Rules

  • Align with the approved stack — don't introduce a second runner without cause.
  • Run what the environment allows; quote results.
  • Flag unrun tests explicitly with the command.

Anti-Patterns

  • 100% coverage mandates that ignore risk.
  • Testing implementation detail instead of behavior.
  • Skipping regression tests on bug fixes.
  • Claiming coverage from tests that never ran.

Validation Checklist

  • Levels matched to risk.
  • Tools matched to apps + stack.
  • Critical path prioritized; deferrals recorded.
  • Regression test for any bug fix.
  • "Tested" bar defined for Gate 5.
  • Actually-run vs unrun stated honestly.

Definition of Done

A recorded testing plan: levels, tools, critical-path coverage, regression tests for fixes, and a clear Gate 5 bar — with honest notes on what was run vs unverified.

Related Skills

feature-planning, bug-investigation, refactor-planning, migration-planning, code-review, stack-recommendation, project-orchestrator.

Related Knowledge

../../knowledge/ (critical paths, invariants).

Related References

../../references/<testing-topic>/ for tool usage if needed.

Context Loading Guidance

  • Requires: the change, its risk, the approved stack, existing test setup.
  • Does not require: unrelated modules, the full reference tree, planning skills' bodies.
  • May load: the relevant planning skill for context; one testing reference folder.
  • Stop when: the testing plan/bar is recorded.

Token Efficiency Guidance

Decide from the risk + stack summary. Keep the plan terse; link tool docs rather than pasting them.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.