Une pyramide de tests plus simple : tirer le meilleur parti de vos tests

Accueil InfoQ Articles Une pyramide de tests plus simple : tirer le meilleur parti de vos tests

Cet article en japonais

10 avril 2023 10 min de lecture

par

Tyson avec plaisir

revu par

Matt Campbell

Les développeurs utilisent de nombreuses étiquettes différentes pour décrire leurs tests automatisés (unité, intégration, acceptation, composant, service, de bout en bout, interface utilisateur, base de données, système, fonctionnel ou API). Chacune de ces étiquettes a une signification sémantique différente, décrivant soit la portée du test, les types d'actions effectuées par le test, le sujet du test ou les collaborateurs du sujet. Nous ne sommes généralement pas d’accord sur la signification de chacune de ces étiquettes, et les discussions sur leur définition ont tendance à être vaines.

Plutôt que de débattre sur les étiquettes à utiliser et sur la manière de les définir, j'ai trouvé plus utile d'utiliser l'un des deux adjectifs suivants pour étiqueter chaque test : lent ou rapide. Ces étiquettes peuvent être tout aussi utiles pour décider de la composition d'une suite de tests tout en permettant aux développeurs de classer objectivement les tests sans arguments improductifs.

Codez, déployez et faites évoluer Java à votre manière. Microsoft Azure prend en charge votre charge de travail avec de nombreux choix, que vous travailliez sur une application Java, un serveur d'applications ou un framework. Apprendre encore plus.

Le choix des étiquettes de test a une influence importante sur la composition d’une suite de tests. Les développeurs les utilisent pour savoir quand écrire un test pour un comportement donné, pour savoir quel type de test écrire et pour évaluer l'équilibre de la suite de tests dans son ensemble. Lorsque nous nous trompons, nous nous retrouvons avec une suite de tests qui soit ne fournit pas de couverture précise, soit propose une couverture à un coût inacceptable.

Quand devez-vous écrire un test pour un élément de code de production donné ? Les développeurs qui, comme moi, pratiquent l'Extreme Programming (XP) ou le Test Driven Development (TDD) répondent souvent à cette question par « toujours ». Cependant, tous les morceaux de code ne doivent pas être automatiquement testés. Pour chaque test proposé, commencez par comparer les coûts de rédaction du test et les avantages.

Je ne m'oppose pas à l'écriture de tests. En effet, pour la plupart des tests, il s’agit d’une vérification rapide et la réponse est oui. Cependant, cette vérification est utile, surtout si un test est lent à exécuter, à écrire ou difficile à maintenir. Dans ces cas-là, posez-vous quelques questions.

Le test est-il coûteux en raison d’une décision de conception ? Le code peut-il être remanié pour mieux s'adapter aux tests ? Vos tests sont les premiers consommateurs de votre code de production. Rendre le code plus facile à tester facilite souvent sa consommation, améliorant ainsi la qualité de votre base de code.

Le test est-il coûteux en raison de l’approche de test ? Une approche de test différente rendrait-elle ce test plus facile à écrire ? Pensez à utiliser des tests doubles comme des contrefaçons ou des simulations à la place des collaborateurs. Si vos tests nécessitent une configuration compliquée, extrayez-la dans un scénario de test qui peut être réutilisé entre les tests.

Attention à ne pas abuser des doubles de tests, car ils n'apportent pas autant de confiance que les vrais collaborateurs. Parfois, cette baisse de confiance vaut la facilité de configuration, la diminution de la durée du test ou l’augmentation de la fiabilité. Cependant, une dépendance excessive à l'égard des doubles de tests peut coupler vos tests à votre implémentation, ce qui entraînera une suite de tests offrant un faible niveau de confiance et inhibant la refactorisation.

Le test est-il coûteux parce que le comportement est intrinsèquement difficile à tester ? Si tel est le cas, considérez l’importance de la fonctionnalité que vous testez. S'il s'agit d'une fonctionnalité critique impliquant le traitement des paiements, le test pourrait en valoir le coût. S'il s'agit d'un cas particulier dans votre logique d'affichage, vous devriez reconsidérer l'opportunité d'écrire ou non le test.

Le test est-il coûteux parce qu’il échoue de manière imprévisible ? Si tel est le cas, vous devez le supprimer, le réécrire pour le rendre plus fiable ou le séparer du reste de votre suite de tests. Pour qu’une suite de tests fournisse des commentaires utiles, vous devez être sûr que les échecs des tests représentent un comportement indésirable. Si vous estimez qu'un test est nécessaire et ne peut pas être rendu prévisible, déplacez-le vers une autre suite de tests exécutée moins fréquemment.