agentleFS
Sign inStart free
caiaffacaiaffa/claude-code-ultimate-engineering-system/skills/test-strategy/SKILL.md

test-strategy

Skill17 starsChanged 58 days agoMITView on GitHub

Define pragmatic, high-confidence test coverage for features, bug fixes, refactors, APIs, workers, queues, and distributed workflows.

39 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use database-testing, data-pipelines and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • petrkindlmannSkill

    database-testing

    Validate database integrity, test migrations forward and backward, verify schema constraints, manage seed data, detect migration drift, and identify query performance issues. Covers PostgreSQL, MySQL, MongoDB with Prisma, TypeORM, Drizzle, and SQLAlchemy, plus Testcontainers test databases. Use when: "database test," "migration test," "migration rollback," "rollback test," "data integrity," "SQL test," "schema validation," "seed data," "query performance," "Testcontainers." Not for: synthetic data generation/masking at scale — use test-data-management; Docker/IaC test-environment provisioning — use test-environments; SQL injection — use security-testing. Related: test-data-management, test-environments, security-testing, ci-cd-integration.

    Also in 3 projects that use this

  • YepAPISkill

    data-pipelines

    ETL patterns, cron scheduling, queue-based processing, and batch jobs with Inngest/BullMQ.

    Also in 3 projects that use this

  • testified-ossSkill

    exploratory-testing

    Guide exploratory testing sessions including charter creation, session-based testing, heuristics application, and finding documentation. Use when planning exploratory testing, conducting test sessions, or documenting discoveries.

    Also in 3 projects that use this

  • ffsshhttiikkSkill

    unit-testing

    Unit testing best practices and patterns

    Also in 4 projects that use this

  • Microsoft AzureSkill

    release-readiness

    Complete ODIN release documentation and validation checks before declaring user-visible work complete, preparing a release, or opening the Release-to-main pull request.

    Also in 4 projects that use this

  • mrgoonieSkill

    context-engineering

    Master context engineering for AI agent systems. Use when designing agent architectures, debugging context failures, optimizing token usage, implementing memory systems, building multi-agent coordination, evaluating agent performance, or developing LLM-powered pipelines. Covers context fundamentals, degradation patterns, optimization techniques (compaction, masking, caching), compression strategies, memory architectures, multi-agent patterns, LLM-as-Judge evaluation, tool design, and project development.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 34 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test the right behavior at the right layer with the least fragility and the highest confidence.

    line 8
  2. Distinctive:

    No test exercises the retry/failure path.

    line 47

“Common” is measured: kept by at least 6 in 10 of the 34 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Mission

Test the right behavior at the right layer with the least fragility and the highest confidence.

When to use

  • Implementing new features.
  • Fixing bugs (regression tests).
  • Refactoring risky paths.
  • Defining coverage for APIs, workers, queues.
  • Reducing flaky or low-value tests.

Handoff

  • Receives from: backend-platform-engineer (after implementation) or code-review (identified gaps).
  • Hands off to: code-review (for final review), release-commander (for deploy).

Test layer selection

What you're testingRight layerWrong layer
Pure business logic (calculations, rules, transforms)Unit testIntegration test (too slow, too coupled)
API contract (request → response shape, status codes)Integration testUnit test (misses middleware, validation)
Database behavior (queries, transactions, constraints)Integration test with real DBUnit test with mocked DB (useless)
Queue consumer (job lifecycle, retries, idempotency)Integration test with real RedisUnit test (misses BullMQ behavior)
Cross-service contractContract testE2E test (too fragile, too slow)
Critical user journeyE2E (sparingly)Everything else (too many E2E = slow CI)

Must-test scenarios for every feature

  1. Happy path — normal flow works.
  2. Validation failures — invalid input rejected correctly.
  3. Error cases — what happens when dependencies fail?
  4. Idempotency — same request twice = same result.
  5. Edge cases — empty, null, max length, boundary values.
  6. Concurrency — two simultaneous requests for the same resource.

Must-test scenarios for bug fixes

  1. Regression test — exact scenario that caused the bug.
  2. Neighboring scenarios — similar inputs that might also fail.

Red flags — test suite is weak if

  • Tests assert framework details (mock called N times) instead of behavior.
  • Tests break when you refactor internals without changing behavior.
  • Database behavior is mocked away for data-critical paths.
  • No test exercises the retry/failure path.
  • 100% coverage but no edge case or failure scenario tests.

Output format

  1. Behaviors to protect (specific, concrete)
  2. Test cases (scenario, expected result, test layer)
  3. Missing coverage (risks not tested)
  4. Implementation order (most critical first)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free