Les tests d'intégration ne sont pas seulement lents, ils sont un tourbillon mortel
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 :
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.
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.
- 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.
