Générateur de Plan de Test

Produis un script shell exécutable qui lance les tests les plus susceptibles de régresser compte tenu des changements de la branche actuelle comparée à master.

La suite de tests complète prend des heures à s'exécuter, l'équipe fusionne donc agressivement et s'appuie sur un passage quotidien de la suite complète qui livre des résultats dans les 24 heures suivant la fusion. Cette skill produit un script préfusion ciblé (moins de 20 minutes) qui atténue les risques sans chercher une couverture complète — son objectif est de détecter les régressions les plus probables, pas toutes les régressions possibles.

Comment Ce Projet Organise les Tests

Consultez le fichier de référence pour connaître les modèles détaillés d'organisation des tests :

${CLAUDE_SKILL_DIR}/references/test-organization.md

Workflow

Comprendre les Changements

git diff master...HEAD --name-only
git log master..HEAD --oneline

Lisez les fichiers modifiés pour comprendre ce que les changements font réellement — non seulement quels fichiers ont été touchés, mais quel comportement a changé. Cette compréhension oriente la sélection des tests.

Identifier Ce Qui Pourrait Régresser

Considérez le rayon d'impact de chaque changement :

Changements d'API ou d'Interface (portal-kernel, modules *-api) : Tout ce qui dépend de l'API modifiée pourrait régresser. Recherchez les consommateurs.
Changements Mécaniques ou Répétitifs (par ex., ajouter une propriété sur 200 fichiers) : Le test de logique centrale est essentiel. Incluez également un échantillon représentatif de tests end-to-end des modules affectés pour vérifier que le changement mécanique n'introduit pas de régressions.
Changements d'Implémentation de Service : Tests du service lui-même, plus tests des fonctionnalités qui en dépendent.
Changements d'Infrastructure Partagée (par ex., un registre, une classe framework, une classe de base) : Chaque module qui s'appuie sur cette infrastructure pourrait régresser. Sélectionnez des tests représentatifs couvrant les modules affectés.
Changements de Couche Web : Tests Playwright et Poshi pour l'interface utilisateur affectée.

L'objectif n'est pas de « trouver tous les tests dans les modules qui ont été touchés » — c'est de trouver les tests qui exercent les chemins de code qui ont changé.

Trouver les Tests

Pour chaque zone qui pourrait régresser, recherchez des fichiers de test. Utilisez des appels Agent et Glob parallèles pour la vitesse. Consultez ${CLAUDE_SKILL_DIR}/references/test-organization.md pour les modèles et conventions exacts.

Vérifiez que chaque fichier de test existe avant de l'inclure dans le plan.

Prioriser Dans le Budget de 20 Minutes

Appliquez l'ordre de priorité suivant :

Toujours inclure :

Tests unitaires pour le code directement modifié — rapides (environ 5–15 secondes par classe) et signal élevé.
Tests d'intégration qui exercent directement la fonctionnalité modifiée.
Tests qui exercent le changement de logique centrale end-to-end.

Inclure si le budget permet :

Tests d'intégration représentatifs des modules aval affectés — choisissez quelques-uns couvrant des modèles d'utilisation distincts plutôt que tous les exécuter.
Tests Playwright pour les modules web affectés (environ 1–3 minutes par spec).

Inclure si toujours dans le budget :

Tests Poshi (environ 2–5 minutes chacun).
Tests de modules aval supplémentaires pour une couverture plus large.

Quand le changement affecte beaucoup de modules (par ex., un changement framework), ne tentez pas de tester chaque module. Choisissez un échantillon diversifié couvrant différents modèles d'utilisation du code modifié.

Écrire le Script

Supprimez tout test.sh existant à la racine du repository, puis écrivez-en un nouveau. Le script doit être autonome et exécutable via bash test.sh. Utilisez cette structure :

#!/usr/bin/env bash
#
# Test plan for branch: <branch-name>
# Generated: <date>
# Estimated time: <X>m / 20m budget
#
# Changes: <N> commits, <N> files changed
# Affected areas: <list of module groups or components>
#

set -o errexit
set -o nounset
set -o pipefail

cd "$(dirname "${BASH_SOURCE[0]}")"

_EXIT_CODE=0

<test commands — one per line, no blank lines between them>

exit ${_EXIT_CODE}

Règles critiques pour le script :

Remplacez <test commands> par les commandes réelles découvertes lors de la sélection.
Suffixez chaque commande avec || _EXIT_CODE=1 pour enregistrer les échecs sans arrêter l'exécution. La récupération || neutralise errexit sur les échecs de test tout en gardant le bloc mode strict en place pour les erreurs non récupérées. Le script se termine avec ${_EXIT_CODE} à la fin — 0 quand tous les tests réussissent, 1 quand l'un échoue.
Utilisez ./gradlew --project-dir ./modules pour les tâches Gradle (le cd du script place la racine du repository comme répertoire de travail).
Utilisez npx --prefix ./modules/test/playwright playwright test pour Playwright.
Tous les types de tests (Unit, Integration, Playwright, Poshi) s'exécutent directement — le portal est supposé fonctionner.
Précédez chaque commande par un commentaire d'une seule ligne expliquant pourquoi elle a été sélectionnée. Énoncez le justificatif ; ne répétez pas le nom du test ou du module.

Après avoir écrit le script, rendez-le exécutable avec chmod +x test.sh et demandez à l'utilisateur de l'exécuter via ./test.sh.

Directives

Vérifiez que chaque fichier de test existe avant de l'ajouter au script.
Quand les changements sont purement cosmétiques (formatage, commentaires), déclarez-le et générez un script qui se termine avec 0 et un en-tête expliquant pourquoi.

test-plan