Ajouter des tests à un code qui n'en a pas, sans rien casser

Le problème de l'œuf et de la poule

Pour modifier un code sans risque, il faut des tests. Pour écrire des tests classiques, il faut savoir ce que le code est censé faire. Et sur un code ancien, ou généré par une IA, personne ne le sait vraiment : la seule vérité, c'est ce que le code fait aujourd'hui.

Les tests de caractérisation partent de cette vérité. Ils ne vérifient pas que le code est juste ; ils vérifient qu'il fait toujours la même chose qu'avant. C'est moins ambitieux, et c'est exactement ce dont on a besoin avant de toucher à un code qu'on ne comprend pas entièrement.

Le principe, en une phrase

On donne au code des entrées réalistes, on enregistre ce qu'il produit, et on fige cet enregistrement comme référence. Ensuite, à chaque modification, on rejoue les mêmes entrées : si le résultat change, le test le signale, et l'on décide si le changement est voulu.

On appelle parfois cet enregistrement de référence le « golden master » : on n'y touche pas sans raison.

Pour un dirigeant : ce que ça change

• Les développeurs peuvent modifier sans casser ce qui marchait, et le prouver.
• Les bugs existants sont enregistrés aussi : c'est voulu. On ne les corrige pas en douce ; on les découvre, on décide, puis on met à jour la référence.
• Un outil d'IA qui modifie le code est pris en flagrant délit quand il change un comportement au passage (voir notre guide Pourquoi l'IA casse ce qui marchait).
• La question à poser à votre prestataire : « avant de modifier, avez-vous de quoi vérifier que rien d'autre ne change ? »

Pour un développeur : la méthode

1. Choisir les parcours critiques, pas tout le code : ceux qui portent l'argent et les données (une commande, un calcul de prix, une facture, un export). Cinq à dix parcours couvrent l'essentiel du risque.
2. Trouver le bon point d'entrée : une fonction de calcul, une route d'API, une requête à la base. Plus on teste haut (une requête HTTP complète), moins on dépend des détails internes qu'on va justement modifier.
3. Préparer des entrées réalistes, y compris les cas limites : panier vide, quantité nulle, date en fin de mois, client sans adresse, montant avec arrondi.
4. Enregistrer les sorties : la réponse renvoyée, les lignes écrites en base, le fichier produit, l'e-mail généré. Les outils de tests par instantané (snapshot) le font automatiquement dans la plupart des langages.
5. Neutraliser ce qui change à chaque exécution : dates du jour, identifiants aléatoires, horodatages. Sinon le test échoue pour de mauvaises raisons.
6. Brancher les tests sur le déploiement, pour qu'une modification qui change un résultat soit bloquée tant que personne ne l'a acceptée.

Ensuite seulement, on refactorise, on corrige, on fait évoluer, en lisant à chaque étape ce que les tests disent.

Un exemple concret

Sur un module de facturation, on prend cent commandes réelles anonymisées, on calcule leurs factures avec le code actuel, et l'on enregistre les montants, ligne par ligne. Le jour où l'on modifie le calcul de la TVA, le test montre exactement quelles factures changent, et de combien. Sans lui, on l'aurait appris par la comptabilité.

Ce que ce guide ne couvre pas

Le choix des outils selon votre langage, l'écriture de tests unitaires classiques une fois le code mieux compris, et la question de savoir ce qui est juste dans le comportement actuel. Installer ces tests sur vos parcours critiques fait partie de la stabilisation : « des tests qui prouvent que ça marche », avant et après.