Compétences en tests de systèmes distribués

Deux compétences qui aident un agent de codage IA à concevoir des tests pertinents, les exécuter et expliquer les résultats pour les systèmes qui stockent des données ou s'exécutent sur plusieurs processus ou machines.

Partez d'une promesse produit — comme « une fois que l'enregistrement réussit, les données sont toujours là après un redémarrage » — et transformez-la en tests que votre agent peut exécuter et vérifier. Utilisez ces compétences pour les bases de données, les files d'attente, les moteurs de workflow et les services où les nouvelles tentatives, les requêtes simultanées ou les défaillances pourraient entraîner une perte ou une duplication de données. Un service s'exécutant sur une seule machine peut également en bénéficier.

Vous n'avez pas besoin d'être un expert en tests. Décrivez la fonctionnalité et ce qui doit rester vrai ; la compétence de conception aide à choisir les tests et à expliquer pourquoi ils sont importants.

Les compétences sont des instructions Markdown, des modèles et du matériel de référence. Votre agent de codage les suit en utilisant les outils de test et l'environnement d'exécution de votre projet. Ce dépôt ne fournit ni exécuteur de tests de base de données ni cluster prêt à l'emploi.

Compétence	Fournissez-lui	Elle produit
Concevoir des tests	Une base de code et la modification ou fonctionnalité que vous souhaitez tester	Un plan expliquant quoi tester, comment le vérifier et combien de tests effectuer
Exécuter des tests	Un plan et un environnement de test	Des résultats, des journaux et données de support, des étapes pour reproduire les échecs et un rapport

Vous pouvez utiliser la compétence de conception seule. L'exécution est une étape distincte qui lit le plan enregistré, vous permettant ainsi de vérifier le travail et son coût avant de l'exécuter.

Commencez par le démarrage rapide, la configuration de Codex ou le guide de l'environnement de test.

Démarrage rapide

1. Installer les compétences

Collez ceci dans votre agent de codage :

Read https://raw.githubusercontent.com/shenli/distributed-system-testing/main/INSTALL.md
and follow the instructions to install or update
distributed-testing-skills for this agent.

Le guide d'installation utilise un checkout partagé dans ~/.local/share/distributed-testing-skills/ et configure des pointeurs ou des liens symboliques pour votre agent. Réutilisez le même prompt pour mettre à jour. Les chemins explicites dans les prompts ci-dessous vous permettent également de charger une compétence sans découverte automatique. Remplacez par votre chemin d'installation si vous avez choisi un autre emplacement.

Pour Claude Code, le dépôt inclut également une option d'installation via plugin :

/plugin marketplace add shenli/distributed-system-testing
/plugin install distributed-testing-skills@distributed-testing-skills

2. Concevoir un plan dans le répertoire de votre projet

Démarrez votre agent dans le dépôt que vous souhaitez tester. Pour une modification spécifique :

Use ~/.local/share/distributed-testing-skills/skills/designing-distributed-system-tests/SKILL.md

Design a test plan for the current branch's changes to adding log entries,
retrying failed requests, and recovering after a crash.
Reuse the existing tests and setup instructions.
Save the plan to docs/testing-plans/append-recovery.md.

Remplacez la fonctionnalité d'exemple par la vôtre. Pour une revue plus large, demandez un plan à l'échelle du projet et nommez les parties à inclure. Ce mode examine les tests existants et identifie les couvertures manquantes à travers le système plutôt qu'un seul changement.

Examinez les promesses vérifiées, les tests proposés, les outils requis et les temps d'exécution. Une faute de frappe dans la documentation ou un changement à faible impact similaire devrait recevoir une recommandation de test allégée plutôt qu'un plan de test distribué.

3. Exécuter le plan contre un environnement de test jetable

Use ~/.local/share/distributed-testing-skills/skills/executing-distributed-system-tests/SKILL.md

Run the small initial checks (the smoke tier) from
docs/testing-plans/append-recovery.md against this project's local test
environment. Keep temporary test scripts and results under
./test-sessions/. Use default mode; do not modify project source files.
Report what ran, what failed, and what remains untested.

La compétence d'exécution découvre les outils existants, demande ce qui est disponible dans votre environnement, puis vérifie les prérequis. Les dépendances manquantes ou les échecs simulés inefficaces doivent être signalés plutôt que comptés silencieusement comme des tests réussis. Commencez petit, puis demandez les exécutions plus longues et plus approfondies définies dans le plan.

Consultez USAGE.md pour les prompts détaillés, les chemins de sortie personnalisés et le mode auteur.

Pour les utilisateurs de Codex

Exécutez le prompt d'installation ci-dessus dans Codex. Le guide crée des liens vers les deux dossiers de compétences depuis le checkout partagé dans ~/.agents/skills/, où Codex les découvre. Pour une installation limitée à un projet, utilisez plutôt le dossier .agents/skills/ de ce projet. Ces emplacements et la prise en charge des liens symboliques sont décrits dans la documentation officielle des compétences Codex.

Ouvrez le projet que vous souhaitez tester. Dans le CLI Codex ou l'extension IDE, utilisez /skills pour vérifier que les deux compétences apparaissent, ou tapez $ pour en sélectionner une. Si une compétence nouvellement installée n'apparaît pas, redémarrez Codex. Vous pouvez également utiliser les prompts explicites avec chemin de fichier dans le démarrage rapide. Consultez les recommandations officielles d'invocation.

Par exemple, demandez à Codex de concevoir un plan :

$designing-distributed-system-tests
Design a test plan for this project's retry and recovery behavior.
I have Docker locally and can run disposable containers.
Start with normal operation, then simultaneous requests and restarts.
Save the plan to docs/testing-plans/retry-recovery.md.

Après l'avoir examiné, exécutez les tests initiaux :

$executing-distributed-system-tests
Run the smoke tier of docs/testing-plans/retry-recovery.md.
Use default mode and save results under ./test-sessions/.
Docker is available; use the project's documented container setup.
Report any missing tools or permissions and which tests they prevent.

L'installation d'une compétence fournit des instructions, pas Docker, un accès distant ou un cluster de test. Codex doit pouvoir atteindre l'environnement où les commandes s'exécuteront. Pour les tests distants, fournissez-lui les hôtes de test, votre méthode de connexion existante et les commandes de configuration du projet. Si l'accès est indisponible, il peut toujours concevoir le plan, mais ne peut pas rapporter que des tests distants ont été exécutés.

Choisir et préparer un environnement de test

Utilisez la configuration la plus légère capable de répondre à votre question. Ce sont des points de départ à adapter à votre application, et non des exigences matérielles ni des recettes de déploiement fournies.