Les tests d'intégration ne sont pas seulement lents, ils sont un tourbillon mortel

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : J.B. Rainsberger
Source : Not Just Slow: Integration Tests are a Vortex of Doom
Date : 2010


Traducteur : Fabrice Aimetti
Date : 26/09/2011


Traduction :

ArtemMarchenko-BlackWhite_bigger.jpg
Ha ha ! Alors @jbrains est vraiment contre les tests d'intégration juste parce qu'ils sont trop lents pour les utiliser à tout moment.
Cela me rappelle l'histoire de Ferrari en informatique (une équipe XP, des dizaines de déploiements par an sur plusieurs continents) qui a commencé par construire un compteur visible pour afficher un grand nombre de tests et qui s'est juste contenté d'en écrire plein.Vous devez commencer quelque part... et faire de grands tests d'intégration est certainement mieux que rien. Du moment que vous êtes prêt à améliorer les pratiques de tests plus tard. Artem-Marchenko

Je suis du même avis. Je repense à ma première tentative d'écriture des tests d'abord[1] , la façon dont j'ai écrit 125 tests, dont beaucoup se définissaient comme des "tests d'intégration", et qui ont pris 12 minutes à s'exécuter. Cela signifiait qu'en moyenne, je ne faisais qu'entre 8 et 12 modifications par heure lors de la rédaction de ce code. J'ai alors constaté, et je continue à le constater encore aujourd'hui, que même en faisant seulement entre 8 et 12 modifications par heure - entre 4 et 6 modifications par heure sur la fin - j'ai produit un meilleur logiciel que lorsque j'ai écrit du code quasi continuellement pendant plusieurs heures. Pour autant que je dénigre ces tests d'intégration aujourd'hui, je les ai grandement apprécié à l'époque où j'en écrivais. Je trouve les tests d'intégration utiles pour trouver des problèmes systèmes, comme première étape de la résolution d'une anomalie, et si je ne peux véritablement pas écrire un test ciblé sur un objet, alors j'ai l'habitude d'écrire un test d'intégration.
Et comme tu le dis, Artem, je ne me suis tout simplement pas arrêter là.
Quand je qualifie les tests d'intégration d'arnaque, je veux insister sur l'aspect auto-réplication des tests d'intégration. Cela commence assez simplement : vous écrivez une poignée de tests d'intégration, qui vous donnent une grande liberté pour mettre en oeuvre votre conception d'une manière qui amène à introduire de fâcheuses dépendances, ce qui rend les tests objets assez difficile. En conséquence, vous devrez probablement vous résigner à écrire plus de tests d'intégration, ce qui ne vous aidera pas à améliorer vos problèmes de dépendances... et le cycle reprend.

cycle-of-pain-1.jpg

Les tests d'intégration génèrent de la douleur, même s'ils semblent à première vue vous aider à réduire cette douleur. C'est là que réside l'arnaque.

Je dois reconnaître ceci : si vous avez commencé à écrire des tests cette semaine, ou ce mois-ci, ou même cette année, alors vous tirerez probablement davantage de bénéfices de l'écriture de tests d'intégration plutôt qu'en essayant d'écrire des tests parfaitement ciblés sur les objets. J'ai déjà dit et écrit ailleurs qu'un programmeur doit écrire environ 1500 tests pour graver dans son cerveau les formes de base de bons tests. Même si, en écrivant ces tests, je souhaite que vous restiez conscient des coûts. Même si vous ne savez pas comment écrire un bon test ciblé sur un objet, si vous voulez écrire plus de tests de cette sorte, et surtout si vous essayez d'écrire plus de tests de cette sorte, alors j'aurai terminé la première phase de ma mission d'éradiquer la confiance du programmeur envers les tests d'intégration pour démontrer la conformité de base de leur code.
Rejoignez-nous ! Transformez aujourd'hui-même un test d'intégration en une petite suite de tests sur les objets. Si vous ne voyez pas encore comment remplacer un test d'intégration entier par un ensemble équivalent de tests ciblés sur des objets, alors écrivez au moins un ou deux tests ciblés sur des objets à côté du test d'intégration. Essayez-les. Je vous garantis que vous aimerez ça.
  1. J'utilise le terme des tests d'abord pour désigner la conception pilotée par les tests sans parler de l'évolution de la conception. Avec les tests d'abord, je développe une conception spécifique, puis j'utilise les tests pour m'aider à l'écrire correctement.

</div>