Test Behaviors, Not Methods! Detecting Tests Obsessed by Methods
Cet article propose une nouvelle odeur de test appelée « Test Obsédé par la Méthode », qui identifie les tests couvrant plusieurs chemins d'exécution d'une seule méthode de production, et valide sa détection par une étude empirique sur la bibliothèque standard de Python montrant que de tels tests vérifient souvent des comportements multiples et peuvent être refactorisés en unités plus focalisées.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous êtes un chef préparant un menu de dégustation pour un critique gastronomique. La règle d'or d'une cuisine exceptionnelle est la suivante : servir une seule saveur distincte par plat. Si vous servez une assiette contenant un steak, une part de gâteau et une boule de glace, le tout mélangé, le critique sera confus. Il ne pourra pas déterminer si le steak est sous-cuit, si le gâteau est trop sucré ou si la glace est en train de fondre. Si quelque chose tourne mal, il ne saura pas quelle partie du repas blâmer.
Dans le monde du logiciel, les « plats » sont des tests et les « saveurs » sont des comportements (ce que le logiciel est censé faire).
Ce document, intitulé « Test Behaviors, Not Methods! », soutient que de nombreux tests logiciels sont actuellement servis comme ce plat mélangé et désordonné. Les auteurs, Andre Hora et Andy Zaidman, introduisent une nouvelle façon de repérer ces tests confus, qu'ils appellent « Tests Obsédés par les Méthodes ».
Voici la décomposition de leur découverte à l'aide d'analogies simples :
1. L'ancienne méthode : Compter les ingrédients
Auparavant, les experts essayaient de trouver ces tests désordonnés en comptant simplement combien de fois un test « touchait » le code. Ils pensaient : « Si un test appelle le code de production 3 fois ou plus, il fait probablement trop de choses. »
Les auteurs appellent cela l'odeur du « Test Avide » (Eager Test). Cependant, ils ont découvert que cette méthode revient à juger un repas uniquement en comptant le nombre de cuillères utilisées. C'est imprécis. Un test peut appeler une fonction de nombreuses fois simplement pour préparer le décor, sans pour autant tester des saveurs différentes. C'est une façon maladroite de identifier le problème.
2. La nouvelle idée : Regarder le film (Analyse au runtime)
Au lieu de simplement compter les cuillerées, les auteurs suggèrent de regarder le film du test pendant qu'il se déroule. Ils proposent une nouvelle règle : Si un seul test force un morceau de code à emprunter plusieurs « routes » (chemins) différentes pour atteindre la ligne d'arrivée, ce test est « obsédé ».
Considérez une méthode de production (un morceau de code) comme un labyrinthe.
- Bon Test : Vous envoyez un explorateur dans le labyrinthe pour vérifier si la porte de gauche fonctionne. Ensuite, vous envoyez un second explorateur pour vérifier si la porte de droite fonctionne. Clair et focalisé.
- Test Obsédé : Vous envoyez un explorateur qui passe par la porte de gauche, puis revient en arrière, passe par la porte de droite, puis tente le tunnel secret, le tout en une seule fois.
Les auteurs appellent cela le « Test Obsédé par la Méthode ». Le test est « gourmand » car il essaie de couvrir tous les chemins possibles d'un seul labyrinthe en une seule fois, plutôt que de diviser le travail.
3. L'expérience : Vérification de la bibliothèque Python
Pour voir si cette « obsession » est un vrai problème, les auteurs ont mené une chasse au trésor à travers la bibliothèque standard Python (une vaste collection de code pré-écrit utilisé par des millions de développeurs).
Ils ont examiné 2 054 tests. Voici ce qu'ils ont trouvé :
- La Chasse : Ils ont trouvé 44 tests qui étaient « obsédés ». Ces tests essayaient de vérifier plusieurs résultats différents d'une seule fonction en une seule fois.
- La Répartition : Ces tests désordonnés ont été trouvés dans 11 des 12 bibliothèques différentes qu'ils ont vérifiées. Ce n'est pas un bug rare ; c'est une habitude courante.
- La Correction : En moyenne, chacun de ces 44 tests désordonnés essayait en réalité de faire deux tâches différentes. Si on les séparait, ces 44 tests pourraient devenir 118 tests propres et focalisés.
- Le Déclic : Dans environ 23 % de ces tests désordonnés, les programmeurs avaient écrit des commentaires admettant : « Hé, nous testons deux choses différentes ici ! » Ils savaient que c'était désordonné, mais ils l'ont fait quand même.
4. Pourquoi est-ce important ?
Les auteurs soutiennent que lorsqu'un test essaie de couvrir trop de chemins à la fois :
- C'est difficile à comprendre : Comme ce plat mélangé, on ne peut pas savoir quelle saveur on déguste.
- C'est fragile : Si vous modifiez le code pour la « porte de gauche », vous pourriez accidentellement casser le test pour la « porte de droite », même s'ils ne sont pas liés.
- C'est difficile à réparer : Lorsqu'un test échoue, on ne sait pas quel comportement spécifique a cassé.
L'essentiel
Le papier ne prétend pas résoudre tous les problèmes de test. Au lieu de cela, il propose un outil plus précis (en utilisant l'analyse au runtime plutôt que le simple comptage) pour repérer les tests qui essaient de faire trop de choses avec un seul morceau de code.
Ils suggèrent que si un test force une fonction à emprunter plusieurs chemins différents, il devrait être divisé. Tout comme un chef doit servir le steak, le gâteau et la glace sur des assiettes séparées, un développeur doit écrire des tests séparés pour chaque comportement distinct.
En bref : Ne soyez pas gourmands avec vos tests. Testez un comportement, un chemin, une saveur à la fois.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.