Les tests dans la chaîne d'intégration

Votre chaîne d'intégration met vingt-six minutes. Un développeur ouvre une demande de fusion, lance l'exécution, passe à autre chose. Une demi-heure plus tard, un test de bout en bout est rouge ; il relance sans regarder, parce que « celui-là échoue de temps en temps ». Cinquante minutes après le premier commit, la fusion passe. Sur cinq demandes par jour, l'équipe a perdu quatre heures d'attente et, surtout, l'habitude de lire les échecs.

C'est le point de bascule à éviter, et il n'a rien à voir avec la qualité des tests pris individuellement. Une suite est utile tant que son verdict arrive assez vite pour rester lié au changement qui l'a déclenché, et tant qu'un test rouge signifie réellement « quelque chose est cassé ». Passé une dizaine de minutes, les gens changent de contexte. Passé quelques échecs aléatoires tolérés, ils cessent de lire. Cette leçon traite donc de deux grandeurs : le temps d'exécution et le taux de faux échecs. Tout le reste en découle.

Découper l'exécution en étages

Ne lancez pas tout au même moment. Les tests rapides doivent donner leur verdict avant que les lents ne démarrent, pour échouer tôt et libérer les agents.