Déployer sans retenir son souffle

Il est 16 h 40, vendredi. Vous devez corriger un libellé dans le tunnel de paiement : trois mots, une ligne. Vous connaissez le fichier, la modification est triviale. Et pourtant vous hésitez, parce que ce composant est importé à sept endroits, que l'un d'eux fait un test d'égalité sur ce libellé pour décider d'afficher un encart promotionnel, et que personne dans l'équipe ne s'en souvient. Vous repoussez au lundi. Ce n'est pas de la prudence, c'est le symptôme d'un code que vous ne pouvez plus modifier avec confiance.

C'est précisément ce que vous achetez avec des tests, et rien d'autre. Un test ne rend pas votre code correct : il était déjà correct ou déjà cassé avant que vous n'écriviez le test. Ce qu'il vous donne, c'est le droit de toucher à ce code demain sans relire les sept fichiers qui en dépendent. Une suite de tests est un contrat exécutable qui répond en trente secondes à la question « est-ce que je viens de casser quelque chose », et cette réponse rapide change complètement le rapport que vous entretenez avec votre propre base de code. Les équipes qui déploient plusieurs fois par jour ne sont pas plus courageuses que les autres ; elles ont simplement automatisé la peur.