Ce qu'il faut tester : Right-BICEP Flashcards
Il peut être difficile de regarder une méthode ou une classe et d’anticiper tous les bogues qui
pourraient s’y cacher. Avec l’expérience, vous développez une idée de ce qui est susceptible de
provoquer des bogues et apprenez à vous concentrer sur le test de ces cas de figure en premier. Ce
dont nous avons besoin, ce sont des directives pour nous aider à comprendre ce qu’il est important
de tester. L’acronyme Right-BICEP vous donne un guide pour poser les bonnes questions sur ce
qu’il faut tester :
Right
Les résultats sont-ils bons ?
Vos tests doivent avant tout valider que le code produit les résultats attendus. Le calcul de la
surface d’une forme géométrique (Votre Laboratoire 7), vous allez construire votre premier test
JUnit qui démontre que la méthode pour la forme géométrique spécifique du triangle produit la
surface correcte de 15 étant donné les nombres 5 (base) et 6 (hauteur). Vous pouvez renforcer un
tel test en ajoutant plus de combinaisons de nombres à la méthode ou en essayant des valeurs
numériques plus grandes. Mais, de tels tests restent du domaine des tests happy-path (chemin
heureux) des cas positifs qui reflètent une partie d’un objectif de l’utilisateur final pour le logiciel.
Si votre code fournit la bonne réponse pour ces cas, l’utilisateur final sera content.
Un test du happy-path représente une réponse à la question importante :
« Si le code fonctionnait correctement, comment le saurais-je ? »
En d’autres termes : si vous ne savez pas comment écrire un test du happy-path pour un petit bout
de code, vous ne comprenez probablement pas entièrement ce que vous essayez de construire et
vous devriez probablement attendre jusqu’à ce que vous pouvez trouver la réponse à la question.
En fait, certains développeurs se posent explicitement cette question à chaque test unitaire qu’ils
écrivent. Ils n’écrivent pas le code avant d’avoir d’abord écrit un test qui montre quelle réponse le
code doit renvoyer pour un scénario donné, à savoir le TDD .
Cependant, les exigences sont parfois vagues ou incomplètes. Rien ne vous empêche de continuer
sans avoir les réponses à vos questions sur ces exigences. Utilisez votre meilleur jugement pour
faire un choix sur la façon de coder les choses, et affinez plus tard le code lorsque les réponses
arrivent du client. La plupart du temps, les choses changent de toute façon : le client change d’avis,
ou quelqu’un apprend quelque chose qui exige une réponse différente. Ainsi, les tests unitaires que
vous écrivez documentent vos choix. Lorsque le changement arrive, vous savez au moins comment
se comporte le code actuel.
B
Toutes les conditions aux limites sont-elles correctes ?
Un code qui teste un happy-path trop évident peut ne pas rencontrer de conditions aux limites dans
le code, à savoir des scénarios impliquant les limites du domaine des valeurs en entrée. La plupart
des erreur impliqueront ces cas particuliers. Vous voudrez donc les couvrir de tests. Les conditions
aux limites auxquelles vous voudrez peut-être penser comprennent :
§ Valeurs d’entrée fausses ou incohérentes, telles qu’un nom de fichier avec des caractères
spéciaux.
§ Données mal formatées, telles qu’une adresse e-mail à laquelle il manque un nom de
domaine ou un « @ » ou un « .com ».
§ Calculs pouvant entraîner un débordement numérique.
§ Valeurs vides ou manquantes, telles que 0, 0.0, “”, ou null.
§ Valeurs bien au-delà des attentes raisonnables, comme l’année de naissance d’une personne
qui est inférieure à 1900.
§ Doublons dans des listes qui ne devraient pas avoir de doublons, comme une liste
d’employés dans un département.
§ Listes ordonnées qui ne le sont pas, et vice versa. Essayez de remettre une liste
préalablement triée à un algorithme de tri, par exemple, ou même une liste triée dans le
sens inverse.
§ Choses qui se produisent hors de l’ordre chronologique attendu, comme un Web service
qui renvoie une réponse pas dans la bonne séquence.
Le code de la méthode de calcul de surface (laboratoire 7) génère une Exception dans la méthode
quand les valeur d’entrée sont négatives. Nous préférons informer les clients dès qu’ils tentent
d’ajouter une valeur invalide. Une clause de test devrait vérifier la plage d’entrée. Par exemple, les
valeurs en entrée très grandes dont le calcul de la surface dépassera la capacité du type de retour
(débordement numérique). Lorsque vous concevez une classe, c’est à vous de décider si des
éléments tels que le débordement potentiel d’entiers doivent être une préoccupation dans le code.
Si votre classe représente une API externe et que vous ne pouvez pas faire entièrement confiance
à vos clients, vous devez vous prémunir contre les mauvaises données. Vous ne voulez
probablement pas autoriser un débordement non contrôlé dans la plupart des systèmes. Mieux vaut
intercepter ces cas de figure et lever une exception (Laboratoire 7).
Pour ce faire, on peut se souvenir des conditions aux limites avec l’acronyme CORRECT. Il vous
permet de mémoriser les conditions limites potentielles. Pour chacun de ces éléments, déterminez
si des conditions similaires peuvent exister dans la méthode que vous souhaitez tester et ce qui
pourrait arriver si ces conditions ne sont pas respectées :
I
Pouvez-vous vérifier les relations inverses ?
Parfois, vous pourrez vérifier le comportement en appliquant son inverse logique. Pour les calculs
mathématiques, c’est souvent le cas : vous pouvez vérifier la division avec la multiplication,
l’addition avec la soustraction, etc. Nous avons décidé d’implémenter notre propre méthode qui
calcule la surface d’un carré (côté2
). Nous rappelons que si nous calculons la racine carrée d’un
nombre et le carré de ce résultat (c’est-à-dire le multiplions par lui-même), nous devrions obtenir
le même nombre avec lequel nous avons commencé. Dans le test, nous dérivons le résultat en
appelant la méthode avec l’argument 5 (coté du carré). Notre assertion s’attend à ce que la racine
carré du résultat sera très proche de la valeur d’origine de 5. Autre exemple, pour le code qui
s’insère dans une base de données, écrivez une requête JDBC directe dans votre test.
Un recoupement peut impliquer de trouver le complément du prédicat. Les réponses positives et
les réponses inverses doivent se combiner pour représenter toutes les réponses. Le recoupement
est un moyen de s’assurer que tout s’additionne et s’équilibre, la liste des employés peut être
reconstituée par la combinaison de la liste des employés retraités et la liste des employés actifs.
C
Pouvez-vous recouper les résultats par d’autres moyens ?.
Tout problème a d’innombrables solutions. Vous choisissez un gagnant parmi les solutions
possibles, parce qu’il est plus performant ou qu’il est plus flexible. Cela laisse les autres solutions
disponibles pour recouper les résultats de production. Peut-être que les finalistes sont trop lents ou
inflexibles pour une utilisation en production, mais ils peuvent vous aider à vérifier votre choix,
en particulier s’ils sont dignes de confiance. Par exemple, supposons que vous développiez un
système de gestion d’une bibliothèque de prêt de livres. Dans une bibliothèque, à un moment
donné, tout doit s’équilibrer. Pour chaque livre, le nombre d’exemplaires empruntés plus le nombre
d’exemplaires en rayon (non empruntés) doit être égal au nombre total d’exemplaires détenus dans
la collection. ils peuvent donc être utilisés pour se recouper. Une autre façon d’envisager le
recoupement est que vous utilisez différentes données de la classe elle-même pour vous assurer
qu’elles s’additionnent toutes (la somme des lignes de commandes donne le total de la commande).
E
Pouvez-vous forcer les conditions d’erreur à se produire ?
L’existence d’un happy-path suggère qu’il doit y avoir un unhappy-path (chemin malheureux). Des
erreurs se produisent, même lorsque vous pensez qu’elles ne le peuvent pas. Les disques se
remplissent, la connexion réseau tombe, et les programmes se bloquent. Vous voulez tester que
votre code gère tous ces problèmes du monde réel d’une manière gracieuse ou raisonnable. Pour
ce faire, vous devez écrire des tests qui forcent les erreurs à se produire. C’est assez facile à faire
avec des paramètres invalides et autres, mais pour simuler des erreurs de réseau spécifiques - sans
débrancher aucun câble - il faut des techniques spéciales, les Mocks (Laboratoire 8). Cependant,
il faut identifier d’abord les types d’erreurs ou à d’autres contraintes environnementales que vous
pourriez introduire pour tester votre code. Voici quelques scénarios à considérer :
§ Manque de mémoire
§ Manque d’espace disque
§ Problèmes avec l’heure du serveur
§ Erreurs et disponibilité du réseau
§ Charge du système (processeur, mémoire, etc.)
§ Palette de couleurs d’affichage limitée
§ Résolution vidéo très élevée ou très faible
Un bon test unitaire n’est pas simplement une couverture exhaustive des chemins logiques évidents
à travers votre code. C’est aussi un effort d’imagination. Certaines des erreurs les plus
problématiques sont les moins attendus.
P
Les caractéristiques de performance sont-elles dans les limites ?
De nombreux programmeurs spéculent sur l’origine des problèmes de performances et sur la
meilleure résolution. Le seul problème est que leurs spéculations sont souvent complètement
fausses. Plutôt que de deviner et de vous attarder sur les problèmes de performances, vous pouvez
concevoir des tests unitaires pour vous aider à savoir où se situent les vrais problèmes et si vos
modifications spéculatives font une différence suffisante. Ce test affirme qu’un bout de code
s’exécute dans un certain laps de temps (Laboratoire 7). Cependant, exécutez aussi les tests de
performances séparément de vos tests unitaires.
CORRECT
§ Conformance : la valeur est-elle conforme au format attendu ?
§ Order : l’ensemble des valeurs est ordonnée ou non ordonnée selon le cas?
§ Range : la valeur est entre les valeurs minimales et maximales raisonnables?
§ Référence : le code fait-il référence à un élément extérieur qui n’est pas sous le contrôle direct du code ?
§ Existence : la valeur existe-t-elle (est-elle nulle, vide, présente dans un ensemble, etc.) ?
§ Cardinality : Y a-t-il exactement assez de valeurs ?
§ Time (absolu et relatif) : Est-ce que tout se passe dans l’ordre? Au bon moment? Dans la
durée?
