Accueil / Gestes courants

Construire et refactorer avec les tests d'abord

Claude Code examine les fichiers de test déjà présents dans un projet pour écrire un nouveau test dans le même style avant l'implémentation, et confirmer que ce test échoue réellement prouve qu'il teste bien quelque chose qui n'existe pas encore.

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 une question gênante : celle 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 : dans les deux cas, la confiance vient d'une sortie lue, pas d'une lecture du code.