MCP HubMCP Hub
SKILL·468093

test-strategy

avelikiy
Mis à jour 3 days ago
1 vues
48
11
48
Voir sur GitHub
Teststestingdesign

À propos

Cette compétence aide les ingénieurs QA à créer des plans de test défendables en remplaçant les pourcentages de couverture insignifiants par des stratégies méthodiques comme les ratios de pyramide de tests et le score de mutation. Elle génère un document TEST-STRATEGY-{slug}.md pour les fonctionnalités de taille moyenne/grande, qui est ensuite validé par une porte de contrôle QA. Utilisez-la lors de la planification des tests pour des changements significatifs afin de garantir que votre couverture reflète réellement une approche de test réfléchie.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add avelikiy/great_cto -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/avelikiy/great_cto
Git CloneAlternatif
git clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/test-strategy

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

test-strategy

Coverage % is a number with no method. This skill makes the QA plan defensible: what to test, why that set, and a real signal that the tests bite.

qa-engineer emits docs/qa-reports/TEST-STRATEGY-{slug}.md capturing the four decisions below; the QA gate checks the file exists for medium/large features.

1. Pyramid ratio — pick by archetype (not by reflex)

The right unit:integration:e2e mix depends on where the risk lives.

Archetypeunitintegratione2ewhy
library / devtools / cli80%15%5%logic-dense, few I/O seams
web-app / saas60%30%10%request→db→render seams dominate
commerce / fintech / marketplace50%35%15%money paths need cross-component proof
data-platform / streaming45%45%10%correctness lives in pipelines, not units
ai-system / agent-product50%20%10% + evals 20%behaviour is the contract → eval set (see [[decision-eval]])

State the chosen ratio in TEST-STRATEGY and justify any deviation.

2. Case selection — equivalence / boundary / property

Don't enumerate inputs; partition them.

  • Equivalence classes — one representative per class of behaviour (valid, invalid, empty, max). Testing 5 valid ids ≠ testing 5 classes.
  • Boundaries — the bug lives at the edge: 0, 1, n-1, n, n+1, off-by-one, empty, overflow, the threshold itself.
  • Property-based — for pure/transform logic, assert invariants over generated input (round-trip decode(encode(x))===x, idempotency, ordering) instead of hand-picked cases. Use fast-check / Hypothesis where the logic warrants it.

3. Mutation score — the only coverage that proves the tests bite

Line/branch coverage proves code ran, not that a test would fail if it broke. Mutation testing (Stryker / mutmut / cargo-mutants) flips operators/conditions and checks a test catches it. A "90% covered" module with 30% mutation score has assertion-free tests. Target: mutation score ≥ 60% on changed logic-dense files; report it in TEST-STRATEGY when the change is logic-heavy. Coverage % is the cheap proxy; mutation score is the truth.

4. Flake quarantine — a flaky test is worse than no test

A test that fails ~randomly trains the team to ignore red. Policy:

  • A test that fails non-deterministically is quarantined (skipped + tracked in a Beads bug), not left to rot the signal.
  • Quarantine is time-boxed: a bug with an owner and a deadline, not it.skip forever.
  • Root-cause before re-enabling (shared state, timing, real network, ordering).
  • This is the same discipline the eval runner needs (see the eval flaky flag in tests/eval/runner.mjs — stddev > 0.1 is a flake signal).

Output: TEST-STRATEGY-{slug}.md

# TEST-STRATEGY-{slug}
- Archetype + chosen pyramid ratio (+ justification for any deviation)
- Equivalence classes & boundaries enumerated per changed unit
- Property-based candidates (which logic, which invariants)
- Mutation-score target + result (for logic-dense changes)
- Quarantine list (flaky tests + their tracking bug)

Done = the plan answers "why THIS set of tests", not just "how much is covered".

Dépôt GitHub

avelikiy/great_cto
Chemin: skills/test-strategy
0
agentic-codingclaude-code-pluginclaude-code-skillsclaude-code-subagentscode-reviewcto
FAQ

Frequently asked questions

What is the test-strategy skill?

test-strategy is a Claude Skill by avelikiy. Skills package instructions and resources that Claude loads on demand, so Claude can perform test-strategy-related tasks without extra prompting.

How do I install test-strategy?

Use the install commands on this page: add test-strategy to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.

What category does test-strategy belong to?

test-strategy is in the Testing category, tagged testing and design.

Is test-strategy free to use?

Yes. test-strategy is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.

Compétences associées

evaluating-llms-harness
Tests

Cette compétence Claude exécute le lm-evaluation-harness pour évaluer les modèles de langage sur plus de 60 tâches académiques standardisées telles que MMLU et GSM8K. Elle est conçue pour permettre aux développeurs de comparer la qualité des modèles, de suivre les progrès de l'entraînement ou de rapporter des résultats académiques. L'outil prend en charge différents backends, incluant les modèles HuggingFace et vLLM.

Voir la compétence
cloudflare-cron-triggers
Tests

Cette compétence fournit une connaissance complète pour la mise en œuvre de Déclencheurs Cron Cloudflare afin de planifier des Workers à l'aide d'expressions cron. Elle couvre la configuration de tâches périodiques, de travaux de maintenance et de flux de travail automatisés, tout en traitant des problèmes courants tels que les expressions cron non valides et les problèmes de fuseau horaire. Les développeurs peuvent l'utiliser pour configurer des gestionnaires planifiés, tester des déclencheurs cron et intégrer avec Workflows et Green Compute.

Voir la compétence
webapp-testing
Tests

Cette Compétence Claude fournit une boîte à outils basée sur Playwright pour tester des applications web locales via des scripts Python. Elle permet la vérification frontend, le débogage d'interface utilisateur, la capture d'écrans et la consultation des journaux, tout en gérant les cycles de vie du serveur. Utilisez-la pour les tâches d'automatisation de navigateur, mais exécutez les scripts directement plutôt que de lire leur code source pour éviter la pollution du contexte.

Voir la compétence
finishing-a-development-branch
Tests

Cette compétence aide les développeurs à finaliser leur travail en vérifiant que les tests passent, puis en présentant des options d'intégration structurées. Elle guide le processus de fusion, de création de PRs ou de nettoyage des branches une fois l'implémentation terminée. Utilisez-la lorsque votre code est prêt et testé pour finaliser systématiquement le cycle de développement.

Voir la compétence