Executing Distributed System Tests

Exécute un plan de test de systèmes distribués conçu, évaluant chaque exécution sur une taxonomie de verdict à 10 états

par shenli · shenli/distributed-system-testing

Fonctionne avec configuration ★ 8.0/10

Executing Distributed System Tests — Exécute un plan de test de systèmes distribués conçu, évaluant chaque exécution sur une taxonomie de verdict à 10 états

Ce que fait

Exécute un plan de test de systèmes distribués précédemment conçu contre un cluster réel ou simulé : découvre la boîte à outils de test existante du SUT, pilote la charge de travail et l'injection de fautes, capture les preuves de nemesis-landing par scénario, et attribue l'un des dix états de verdict avec des audits green-but-broken et weak-oracle avant tout PASS. Se déclenche sur "execute the plan", "reproduce a distributed bug", "run stability/chaos tests", "validate a release end-to-end", ou lorsqu'un fichier de plan existe à docs/testing-plans/. Pour les scénarios de limite et d'équité, il évalue chaque bras de surface séparément et applique une règle de dégradation afin qu'un bras non testé ne puisse pas se fondre dans une réussite de scénario.

Rapport de test

SKILL.md récupéré via l'API GitHub ; le frontmatter est parsé (name+description), et 3 fichiers référencés dans le corps ont renvoyé HTTP 200 (verdict-taxonomy.md, green-but-broken-red-flags.md, findings-report-template.md). Pas de chemins codés en dur ni de failles de sécurité ; livre des fichiers plugin.json/marketplace.json valides. Le chemin d'exécution complet (pilotage de l'injection de fautes contre un cluster live) nécessite Docker + un SUT distribué + un fichier de plan conçu que je n'ai pas pu fournir, j'ai donc mesuré la tranche distinctive de verdict/discipline de rapport de la compétence : étant donné un scénario de limite avec 4 bras de surface où 2 ont réussi et 2 n'ont jamais été atteints, ma référence l'a appelé "PASS (avec réserves), rien n'empêche l'expédition", tandis que le suivi de la règle de dégradation par bras du corps a forcé "PARTIAL-surface, PAS une réussite, ne devrait PAS être expédié" plus un tableau de couverture de surface — l'échec exact de surface repliée que la compétence prétend prévenir (exec_baseline.md vs exec_skill.md).

Testé le: 2026-07-31 · Claude Code 2.x (agent harness)

Installation

git clone --depth 1 https://github.com/shenli/distributed-system-testing.git /tmp/executing-distributed-system-tests-src
mkdir -p ~/.claude/skills
cp -R /tmp/executing-distributed-system-tests-src/skills/executing-distributed-system-tests ~/.claude/skills/executing-distributed-system-tests
# Plugin-marketplace alternative: /plugin marketplace add shenli/distributed-system-testing  then install the 'distributed-testing-skills' plugin (installs both design + execute skills)
# To ACTUALLY RUN a plan end-to-end you additionally need, none of which the skill bundles:
#   - a plan file produced by the paired 'designing-distributed-system-tests' skill (the skill halts if oracles/budget tiers are missing)
#   - a distributed system-under-test repo to run against
#   - container + fault-injection tooling: docker/podman + compose, iptables/tc/netem, optionally toxiproxy/libfaketime

Commandes et exemples de prompts

/executing-distributed-system-testsExécute un plan de test de systèmes distribués conçu, évaluant chaque exécution sur une taxonomie de verdict à 10 états

Les skills se déclenchent sur des demandes en langage courant — aucune commande à retenir. Après installation, des prompts comme ceux-ci l'activent (en anglais) :

Execute the test plan against the staging cluster
Reproduce this distributed bug with chaos testing
Run tenant isolation tests before this release

Rapport complet →