Accueil / Quand ça déraille

Lire la fonction appelée, prouver le coupable

Un correctif dont le test unitaire passe au vert peut être annulé, dans le même tour d'exécution, par la fonction appelée juste après, et la fonction déjà corrigée n'est un coupable prouvé qu'après qu'un test a isolé son effet de celui des fonctions suivantes.

Un correctif qui corrige exactement la fonction fautive, avec un test unitaire qui passe au vert, peut ne rien changer à ce que voit l'utilisateur. La cause tient à une seule chose : la fonction que vous venez de corriger n'est presque jamais la dernière à toucher la valeur. Le résultat corrigé passe encore, dans le même tour d'exécution, par une ou plusieurs fonctions appelées juste après, et l'une d'elles peut annuler le correctif sans qu'aucun test ne le signale.

Le correctif qui ne survit pas à l'appel suivant

Prenez un cas fabriqué pour tenir seul, sans dépendre d'aucun fichier du projet. La fonction formatPrice arrondissait mal un prix en centimes, le correctif la fait désormais arrondir à deux décimales. Son propre test passe. Le prix affiché à l'écran reste pourtant faux, parce qu'une fonction appliquée juste après, applyDiscount, retransforme ce texte en nombre puis l'arrondit une seconde fois vers le bas.

function formatPrice(cents) {
  return (cents / 100).toFixed(2); // corrigé : deux décimales exactes
}

function applyDiscount(priceText) {
  const price = parseFloat(priceText);
  return Math.floor(price * 0.9); // arrondit encore, vers le bas
}

console.log(formatPrice(1299));                 // 12.99, le correctif fonctionne seul
console.log(applyDiscount(formatPrice(1299)));  // 11, le correctif est annulé

Le premier appel prouve que formatPrice est correcte. Le second appel, celui qui atteint réellement l'écran, prouve le contraire. Un correctif se prouve sur ce second chiffre, jamais sur le premier.

Le coupable plausible n'est pas le coupable prouvé

Devant un affichage encore faux après un correctif, la fonction déjà modifiée redevient le premier suspect. C'est un coupable plausible, pas un coupable prouvé. Pour trancher, lisez les premières et les dernières instructions de chaque fonction appelée juste après celle qui vient d'être corrigée, pas seulement la fonction elle-même. Dans l'exemple, la dernière instruction d'applyDiscount, Math.floor, est la ligne qui efface les centimes que formatPrice venait de restituer.

La preuve finale ne se lit pas dans le code, elle se lit dans une sortie. Écrivez un test qui isole exactement l'entrée et la sortie visibles à l'écran, en l'occurrence la valeur que renvoie applyDiscount, et lisez ce que ce test rend réellement avant de désigner un coupable. C'est le même principe que vérifier l'état réel avant d'agir sur une demande : un correctif s'établit sur le rendu produit, jamais sur la lecture du code censé le produire.

Quand le coupable reste indéterminé

Deux fonctions appelées dans le même tour peuvent chacune modifier la même valeur d'une manière qui produit, isolément, un résultat plausible. Un test qui ne sépare pas leurs effets ne départage rien. Dans ce cas, la réponse correcte n'est pas de choisir une fonction au hasard pour clore le sujet : elle consiste à écrire deux tests distincts, un par fonction suspecte, isolant chacune de l'autre, puis à dire que l'identité du coupable reste indéterminée tant que ces deux tests n'ont pas été exécutés et lus.