This is an old revision of the document!

---

Écrire des tests unitaires pour des classes non triviales est souvent un processus créatif difficile, un peu comme écrire un code de production. Pour cette raison, il n'existe pas de formule ou de modèle standard pour écrire le code d'un test unitaire. En fait, parcourir les suites de tests de différents projets open-source montrera que les différentes communautés suivent des styles différents et utilisent des techniques de test différentes. Ceci étant dit, certains principes de base sont généralement acceptés, notamment que les tests unitaires doivent être rapides, indépendants, répétitifs, ciblés et lisibles[7]. - Jeûne. Les tests unitaires sont destinés à être exécutés souvent, et dans de nombreux cas dans le cadre d'un cycle de programmation-compilation-exécution. Pour cette raison, n'importe quelle suite de tests exécutée devrait être capable de se terminer en quelques secondes. Sinon, les développeurs seront tentés d'omettre de les exécuter, et les tests cesseront d'être utiles. Cela signifie que les tests unitaires doivent éviter les opérations de longue haleine telles que les E/S d'appareils intensifs et l'accès au réseau, et laisser le test de ces fonctions à d'autres tests que les tests unitaires. Il peut s'agir, par exemple, de tests d'acceptation ou d'intégration. - Indépendant. Chaque test unitaire devrait pouvoir être exécuté de façon isolée. Cela signifie, par exemple, qu'un test ne doit pas dépendre du fait qu'un autre test s'exécute avant de laisser un objet d'entrée dans un certain état. Premièrement, il est souvent souhaitable de n'effectuer qu'un seul test. Deuxièmement, tout comme le code, les suites de tests évoluent, avec l'ajout de nouveaux tests et (dans une moindre mesure) la suppression de certains tests. L'indépendance des tests facilite l'évolution de la suite de tests. Enfin, JUnit et d'autres tests de conception similaire 6 Cependant, seules les instances d'annotations de types d'annotations marquées par la méta-annotation @Retention- (value=RUNTIME) sont accessibles de cette manière. Voir Lectures complémentaires pour une référence à des informations complémentaires sur les annotations qui couvrent les méta-annotations.

5.5 StructuringTests 103 n'offrent aucune garantie que les tests seront exécutés dans un environnement prévisible ou- der. En pratique, cela signifie que chaque test doit commencer par une nouvelle initialisation de l'état utilisé dans le cadre du test. - Répétable. L'exécution de tests unitaires devrait produire le même résultat dans des environnements différents (par exemple, lorsqu'ils sont exécutés sur des systèmes d'exploitation différents). Cela signifie que les oracles de test ne doivent pas dépendre de caractéristiques propres à l'environnement, telles que la taille de l'affichage, la vitesse du CPU ou les polices système. - Concentré. Les tests doivent exercer et vérifier une partie du comportement d'exécution du code qui est aussi étroite que raisonnablement possible. La raison d'être de ce principe est que le but des tests unitaires est d'aider les développeurs à identifier les pannes. Si un test unitaire comprend 500 lignes de code et teste toute une série d'interactions complexes entre objets, il ne sera pas facile de déterminer ce qui a mal tourné en cas d'échec. En revanche, un test qui vérifie une seule entrée sur un seul appel de méthode facilitera le repérage d'un problème. Certains ont même soutenu que les tests unitaires devraient comporter une seule affirmation[7]. Mon opinion est que dans de nombreux cas, cela est trop strict et peut conduire à des inefficacités. Toutefois, les tests devraient idéalement se concentrer sur un seul aspect d'une unité à l'essai. Si l'unité testée est une méthode, nous pouvons l'appeler méthode focale pour le test. - Lisibles. La structure et le style de codage du test devraient faciliter l'identification de toutes les composantes du test (unité sous test, données d'entrée, oracle), ainsi que la justification du test. Testons-nous l'initialisation d'un objet ? Un cas particulier ? Une combinaison particulière de valeurs ? Le choix d'un nom approprié pour le test peut souvent aider à clarifier sa raison d'être. Par exemple, écrivons quelques tests unitaires pour une méthode canMoveTo d'une classe hypothétique FoundationPile qui pourrait faire partie de la conception de l'application Solitaire exemple. La méthode ne doit retourner true que s'il est possible de déplacer la carte d'entrée pCard vers le haut de la pile qu'une instance de la classe représente. Selon les règles du jeu, cela n'est possible que si la pile est vide et que la carte d'entrée est un as, ou si la carte d'entrée est de la même couleur que le haut de la pile, et d'un rang immédiatement au-dessus du haut de la pile (par exemple, vous ne pouvez mettre un trois de trèfle sur un deux de trèfle).

Traduit avec www.DeepL.com/Translator