Accueil / Gestes courants

Construire et refactorer avec les tests d'abord

Demandez les tests avant l'implémentation, puis lancez le lanceur de tests pour constater qu'ils échouent réellement : le rouge prouve que le test peut échouer, le vert que l'implémentation le satisfait. Claude reproduit le style des tests déjà présents dans le dépôt, puis le refactor avance une préoccupation à la fois.

Claude examine les fichiers de test déjà présents dans un dépôt pour reproduire leur style, leur cadre de test et leurs conventions d'assertion, plutôt que d'imposer une convention étrangère au projet. Le geste consiste à demander ces tests avant d'écrire l'implémentation qu'ils doivent vérifier, puis à lancer le lanceur de tests pour constater qu'ils échouent réellement.

Confirmer le rouge avant de demander le vert

Cette séquence, connue en génie logiciel sous le nom de rouge, vert, refactor, ne dépend d'aucune fonctionnalité spécifique de Claude Code, elle reste valable avec n'importe quel outil. Le rouge prouve que le test peut échouer, le vert prouve que l'implémentation le satisfait, et sauter directement au vert sans avoir vu le rouge laisse ouverte la question de savoir si le test aurait passé même sans aucune implémentation.

L'exemple suivant fabrique ses propres données pour rester valable à toute lecture. Un test attend qu'une fonction calculerRemise applique dix pour cent de réduction, avant même que cette fonction existe.

function testCalculerRemise() {
  const resultat = calculerRemise(200);
  console.assert(resultat === 180, "attendu 180, obtenu " + resultat);
}

testCalculerRemise();
// ReferenceError: calculerRemise is not defined, le rouge attendu

Une fois ce rouge constaté, l'implémentation minimale suffit à le faire passer au vert.

function calculerRemise(prix) {
  return prix * 0.9;
}

testCalculerRemise();
// aucune sortie : l'assertion est vraie, le test est au vert

Refactorer une préoccupation à la fois

Le lanceur de tests reste actif pendant tout le refactor qui suit, et chaque modification porte sur une seule préoccupation, un seul nom renommé, une seule fonction extraite, jamais plusieurs à la fois dans le même tour. Cette discipline isole la régression : si le lanceur de tests échoue après un changement, la cause tient dans ce changement précis, pas dans un ensemble de modifications empilées qu'il faudrait démêler. Demander explicitement à Claude d'identifier les cas limites non couverts avant de considérer une série de tests terminée complète le tableau, en particulier sur les entrées vides, négatives ou hors bornes que l'implémentation initiale ignore souvent.

Cette exigence de preuve exécutée rejoint le test de régression qui clôt une correction de bug.

Éprouver les tests avec des mutants

Un test au vert prouve que le code passe, pas que le test détecte une faute. Un mutant est une faute injectée volontairement dans une copie du code : si la suite passe encore, elle est aveugle à cette faute. Le script crée une fonction et son test, puis un mutant qui change 0.9 en 0.8.

cat > remise.js << 'EOF'
function calculerRemise(prix) { return prix * 0.9; }
module.exports = { calculerRemise };
EOF
cat > test.js << 'EOF'
const { calculerRemise } = require('./remise.js');
if (calculerRemise(200) !== 180) { console.log('ECHEC'); process.exit(1); }
console.log('OK');
EOF
node test.js
cp remise.js remise.orig.js
sed -i 's/0\.9/0.8/' remise.js
node test.js; echo "code=$?"
cp remise.orig.js remise.js
node test.js

OK
ECHEC
code=1
OK

Le mutant est tué, puisque le test échoue. Lancez d'abord le seul test ciblé, plus rapide que la suite entière, puis la suite complète pour les seuls mutants survivants. Restaurez la copie d'origine entre deux mutants, et vérifiez que le code d'origine passe, faute de quoi un échec ne prouve rien.

Une non-régression se construit

Quand une correction change ce qu'une règle de détection compte, énumérer les formes à ne pas perdre échoue : un vérificateur en trouve toujours une de plus. Gardez plutôt l'ancienne règle à part, jugez les mêmes entrées avec l'ancienne et la nouvelle, et exigez que toute différence vienne de la consigne. Pour un compteur de mots qui passe d'une séparation sur un espace à une séparation sur toute suite d'espaces, la différence attendue porte sur les espaces en trop, et sur eux seuls.