Quels tests écrire quand on n'a pas le temps de tout tester
Ayoub
Tech Lead
En bref
Quels tests automatisés écrire en priorité sur une application métier ?
Trois familles, dans cet ordre : les tests des règles de gestion — celles qui coûtent de l'argent si elles se trompent ; les tests des parcours critiques de bout en bout, deux ou trois maximum ; et un test de non-régression pour chaque bug corrigé. Chercher un taux de couverture élevé est une mauvaise cible : une couverture de 40 % concentrée sur les règles métier protège mieux qu'une couverture de 80 % répartie uniformément.
« On n’a pas le temps d’écrire des tests. » Je l’entends souvent, et le plus souvent c’est vrai — le budget est ce qu’il est.
La question n’est donc pas de savoir s’il faut tout tester, mais où mettre les quelques heures disponibles. Ce choix se fait mal par instinct, et bien avec une règle simple.
La règle : tester ce qui coûte cher quand c’est faux
Un test protège une chose. Le seul critère utile est : combien coûte une erreur à cet endroit ?
Un calcul de remise qui se trompe génère des factures fausses, des avoirs, du temps administratif et un client mécontent. Un libellé mal aligné agace pendant une semaine.
Ce ne sont pas les mêmes enjeux, donc pas les mêmes priorités. C’est évident écrit ainsi, et pourtant l’instinct pousse à tester ce qui est facile à tester — c’est-à-dire souvent le moins risqué.
1. Les règles de gestion
C’est le premier poste, et le plus rentable de tous.
Calculs de prix, de remises, de taxes. Conditions d’éligibilité. Transitions de statut autorisées. Attribution de droits. Règles de prorata, d’arrondi, de date d’effet.
Ces règles ont trois propriétés qui les rendent idéales à tester : elles sont pures — mêmes entrées, mêmes sorties, sans dépendance externe —, elles sont rapides à exécuter, et une erreur s’y traduit directement en euros.
Un point sur lequel j’insiste : testez les cas limites, pas le cas nominal. La remise à 10 % sur 100 € fonctionne. Ce qui casse, c’est le montant à zéro, le montant négatif, l’arrondi au demi-centime, la date exactement à la limite de validité, et la remise cumulée avec une autre.
2. Deux ou trois parcours critiques, de bout en bout
Ensuite, et seulement ensuite : les parcours complets, simulés comme un utilisateur.
Deux ou trois, pas plus. Ceux dont l’indisponibilité vous ferait appeler un dimanche — se connecter, créer et valider un dossier, payer.
Ces tests sont précieux parce qu’ils vérifient l’assemblage : la base, l’authentification, les appels externes, l’interface. Ils attrapent les pannes que les tests unitaires ne voient jamais.
Ils sont aussi les plus coûteux à maintenir : lents, sensibles au moindre changement d’interface, et parfois instables. C’est exactement pour cela qu’il faut s’en tenir à deux ou trois. Une suite de cinquante tests de bout en bout finit toujours par être ignorée parce qu’elle échoue « pour rien » — et le jour où elle échoue pour une vraie raison, personne ne regarde.
Photo : rawpixel — licence CC0.
3. Un test par bug corrigé
La règle la plus simple à appliquer et la plus sous-estimée.
Chaque fois qu’un bug est corrigé, écrire le test qui échouait avant la correction. C’est rapide — le cas est connu, il vient d’être reproduit — et cela garantit qu’il ne reviendra pas.
L’intérêt de cette pratique est qu’elle construit une couverture guidée par la réalité. Après un an, la suite de tests couvre précisément les endroits où le code s’est déjà cassé, c’est-à-dire là où il est fragile. Aucune stratégie théorique ne produit une couverture aussi bien ciblée.
Photo : Kristin Hardwick — licence CC0.
Ce que je ne teste pas
Les accesseurs et le code trivial. Un test qui vérifie qu’un champ affecté est bien lu ne protège de rien et gonfle artificiellement la couverture.
Les bibliothèques externes. Elles ont leurs propres tests. Je teste mon usage, pas leur fonctionnement.
L’apparence. Le rendu visuel se vérifie à l’œil ou par des outils dédiés, pas par des tests fonctionnels qui casseront à chaque ajustement de mise en page.
Le code que je m’apprête à supprimer. Cela paraît évident et arrive plus souvent qu’on ne croit.
Pourquoi le taux de couverture est une mauvaise cible
Un chiffre de couverture ne dit pas ce qui est couvert. Une application à 80 % dont les 20 % non couverts sont exactement les règles de calcul est moins protégée qu’une application à 40 % concentrée sur ces règles.
Pire, viser un pourcentage encourage à écrire des tests faciles et sans valeur pour atteindre le seuil. J’ai vu des suites de tests qui n’échouaient jamais, quoi qu’on casse.
Ce que je regarde à la place : est-ce que la suite de tests a déjà attrapé un vrai bug ce trimestre ? Si oui, elle sert. Si non, elle décore.
Photo : rawpixel — licence CC0.
Les tests qui coûtent plus qu’ils ne rapportent
Certains tests ont un coût de maintenance supérieur à leur valeur. Je les identifie à trois signes.
Ceux qui cassent à chaque changement d’interface. Un test qui cible un texte de bouton ou une position dans le DOM échouera à la première retouche graphique, sans qu’aucune régression réelle n’ait eu lieu. On les répare, on s’agace, puis on les désactive.
Ceux qui dépendent de l’heure ou de l’ordre d’exécution. Un test qui passe le matin et échoue après minuit, ou qui échoue quand il tourne seul, entraîne une conséquence désastreuse : l’équipe apprend à relancer sans regarder. Le jour où un vrai bug apparaît, personne ne le voit.
Ceux qui reproduisent la logique testée. Si le test recalcule le résultat attendu avec la même formule que le code, il ne teste rien : il vérifie que la formule est égale à elle-même. Les valeurs attendues doivent être écrites en dur, calculées à la main.
Ce que je fais avant de corriger un bug
Une habitude qui a plus changé ma façon de travailler que n’importe quelle méthode : écrire le test avant la correction.
Cela paraît contre-intuitif quand on est pressé. En pratique, cela va plus vite.
Écrire le test oblige à reproduire le bug de façon fiable, donc à le comprendre vraiment — et non à deviner. Beaucoup de corrections rapides traitent un symptôme et laissent la cause en place ; le bug revient trois semaines plus tard sous une autre forme.
Et une fois le test écrit, on sait exactement quand on a fini : quand il passe. Sans lui, on corrige, on essaie à la main, et on n’est jamais tout à fait sûr.
Par où commencer sur une application sans aucun test
Ne cherchez pas à rattraper l’existant : c’est décourageant et le chantier n’aboutira pas.
Commencez par la règle du bug corrigé. Elle ne demande aucun budget supplémentaire, s’intègre au travail courant, et cible naturellement les zones fragiles.
Ajoutez, quand l’occasion se présente, les tests des règles de gestion que vous devez modifier. Vous les testez au moment où vous les touchez — c’est là que le test coûte le moins cher, parce que le contexte est déjà en tête.
Six mois plus tard, sans avoir jamais lancé de « chantier tests », vous aurez une suite qui couvre l’essentiel.