« Encore ce test qui casse ? » Cette phrase, prononcée en revue de code pour la cinquième fois à propos du même fichier de tests sur les commandes groupées d’une extension de réservation, est en général le signal qu’il ne s’agit plus d’un bug isolé mais d’une dette accumulée. Chaque correctif rapide a résolu le symptôme du jour sans jamais interroger la conception du test lui-même.
La question n’est pas de savoir si un test fragile mérite un correctif de plus. Elle est de savoir à partir de quel moment ajouter un correctif de plus coûte plus cher que de réécrire la portion concernée depuis une base saine.
Le signal le plus fiable : le nombre de corrections sur le même test
Un test qui échoue une fois pour une raison légitime, comme un changement de comportement métier volontaire, ne pose pas de problème structurel. Un test corrigé plusieurs fois pour des raisons différentes mais liées à la même zone du code, en revanche, indique presque toujours que le test lui-même est mal conçu : il vérifie trop de choses à la fois, dépend d’un état global fragile, ou repose sur une fixture partagée modifiée ailleurs sans que personne n’ait mesuré l’impact.
Dans le cas observé, le test test_calcul_total_commande_groupee avait été corrigé cinq fois en huit mois, chaque fois pour un motif différent : une fixture de produit modifiée, un arrondi changé, une nouvelle règle de remise ajoutée en urgence dans l’assertion existante plutôt que dans un nouveau cas dédié.
Le second signal : le temps de compréhension dépasse le temps d’écriture
Un test bien conçu se comprend en quelques secondes : son nom décrit le comportement vérifié, sa préparation est courte, son assertion est unique. Quand la revue d’un échec de test nécessite de dérouler plusieurs fonctions d’assistance, de relire l’historique Git pour comprendre pourquoi telle valeur a été codée en dur, ou de demander à un collègue « pourquoi ce test existe », le coût de maintenance a dépassé depuis longtemps le coût d’écriture initial.
Un indicateur simple à suivre
Sans outillage complexe, il suffit de noter dans le message de chaque commit de correction de test le nom du fichier concerné. Un script court permet ensuite de repérer les fichiers de tests les plus souvent corrigés sur une période donnée :
git log --since="6 months ago" --name-only --grep="fix.*test" \
-- tests/ | sort | uniq -c | sort -rn | head -10
Ce que « réécrire » signifie concrètement
Réécrire ne veut pas dire supprimer et recommencer à l’aveugle. Cela signifie reprendre la portion concernée avec ces trois principes :
- Un cas de test par comportement métier, jamais une accumulation d’assertions dans une seule méthode.
- Des fixtures dédiées à la portion réécrite, sans dépendance à un état préparé ailleurs dans la suite.
- Des noms de méthode qui décrivent le résultat attendu plutôt que l’action technique, par exemple
test_remise_fidelite_ne_s_applique_pas_sous_le_seuil_minimum().
Estimer le coût de la réécriture avant de s’engager
Réécrire une portion de suite de tests représente un investissement qu’il faut pouvoir justifier. Un tableau de décision simple, rempli en une demi-heure de discussion d’équipe, aide à trancher :
| Critère | Continuer à corriger | Réécrire |
|---|---|---|
| Corrections sur 6 mois | 1 ou 2 | 4 et plus |
| Zone du code encore active | Peu de changements prévus | Évolutions fréquentes à venir |
| Compréhension par un nouvel arrivant | Rapide | Nécessite une explication orale |
Un test qu’on n’ose plus toucher de peur de casser autre chose n’est déjà plus un filet de sécurité : c’est une source d’anxiété qu’on paie à chaque mise à jour.
Traiter la réécriture comme une tâche à part entière
Glisser une réécriture de tests entre deux tâches fonctionnelles urgentes garantit qu’elle sera bâclée ou reportée indéfiniment. Elle mérite d’être planifiée comme une tâche identifiée, avec un temps estimé et un critère de sortie clair : la portion réécrite doit passer au moins un cycle de développement sans nécessiter le moindre correctif pour être considérée comme assainie.
Notre verdict
Le nombre de corrections successives sur un même test, plus que son ancienneté ou sa complexité apparente, reste l’indicateur le plus fiable pour décider de réécrire. Attendre la cinquième correction, comme dans le cas de la commande groupée, coûte largement plus cher que d’avoir agi dès la troisième. La dette de tests, comme toute dette, s’alourdit avec le temps qui passe sans remboursement.
