Tests : combien, lesquels et lesquels ne valent pas la peine
Trois couches
Unitaires. Rapides, ciblés, qui tournent à chaque sauvegarde. C'est là que se trouve la plupart du retour.
Intégration. Contre une vraie base de données et de vraies files. Attrape ce que les unitaires manquent — schéma, transactions, requêtes.
Bout à bout. Coûteux et fragiles. Réservez-les à cinq à quinze chemins critiques.
Ce qui vaut la peine d'être testé
La logique métier avec les cas limites, les calculs, les permissions et tout ce qui a déjà cassé une fois. Chaque bug corrigé reçoit un test — ainsi la couverture grandit aux bons endroits et non par pourcentages.
Ce qui ne vaut pas : du code qui ne fait que déplacer des données, et des tests qui simulent tellement qu'ils testent la simulation et non le système.
La qualité du test
Un bon test échoue pour une raison claire et nomme ce qui s'est cassé. Un test instable est pire qu'aucun test — il enseigne à l'équipe à ignorer le rouge.
Pour aller plus loin
Séparez les tests rapides qui tournent à chaque poussée d'une suite lourde qui tourne la nuit. Et quand un test échoue par intermittence, traitez-le comme un bug de haute priorité — tolérer l'instabilité efface en mois toute la valeur de la suite.