Cela faisait longtemps que je n’avait pas écrit sur une des règles du livre 97 Things every programmer should know.
Aujourd’hui, je vais parler de la partie de Gerard Meszaros, sur l’écriture des tests pour les autres personnes travaillant sur le projet.
Voici ce que nous raconte Gerard Meszaros, en français :
Vous écrivez des tests automatisés pour tout ou partie de votre code de production. Toutes mes félicitations!
Vous écrivez vos tests avant d’écrire le code ? Encore mieux !!
Cela fait de vous l’un des premiers utilisateurs à la pointe de la pratique du génie logiciel.
Mais écrivez-vous de bons tests ? Comment pouvez-vous le juger ?
Une solution consiste à demander : Pour qui est-ce que j’écris les tests ?
Si la réponse est « Pour moi, m’épargner l’effort de corriger les bogues» ou « Pour le compilateur, afin qu’ils puissent être exécutés », alors il y a de fortes chances que vous n’écriviez pas les meilleurs tests possibles.
Dans ce cas, pour qui devriez-vous écrire les tests ?
Pour les personnes essayant de comprendre votre code. Les bons tests servent de documentation pour le code qu’ils testent. Ils décrivent le fonctionnement du code. Pour chaque scénario d’utilisation, les tests doivent :
- Décrire le contexte, le point de départ ou les conditions préalables à satisfaire
- Illustrer la manière dont le logiciel est appelé
- Décrire les résultats attendus ou les post-conditions à vérifier
Différents scénarios d’usages auront des versions légèrement différentes de chacun d’eux. La personne qui essaiera de comprendre votre code doit pouvoir examiner quelques tests et, en comparant ces trois parties, permettre de voir ce qui provoque un comportement différent du logiciel.
Chaque test doit clairement illustrer la relation de cause à effet entre ces trois parties. Ce qui n’est pas visible dans le test est tout aussi important que ce qui est visible.
Trop de code dans le test distrait le lecteur avec des anecdotes sans importance. Dans la mesure du possible, cachez ces anecdotes derrière des appels de méthode significatifs: le refactoring est votre meilleur ami.
Et assurez-vous de donner à chaque test un nom explicite décrivant le scénario d’utilisation en question, afin que le lecteur n’ait pas à désosser chaque test pour comprendre quels sont les différents scénarios.
Entre eux, les noms de la classe de test et de la méthode de classe doivent inclure au moins le point de départ et la manière dont le logiciel est appelé. Cela permet de vérifier la couverture du test via un balayage rapide des noms de méthodes. Il peut également être utile d’inclure les résultats attendus dans les noms des méthodes de test, à condition que leur nom ne soit pas trop long à afficher ou à lire.
C’est également une bonne idée de tester vos tests.
Vous pouvez vérifier qu’ils détectent les erreurs que vous pensez détecter en les insérant dans le code de production (votre propre copie privée que vous allez jeter, bien sûr).
Assurez-vous qu’ils signalent les erreurs de manière utile et significative.
Vous devez également vérifier que vos tests parlent clairement à une personne qui tente de comprendre votre code.
La seule façon de le faire est d’avoir une personne qui ne connaît pas votre code qui lit vos tests et vous dit ce qu’elle a appris.
Écoutez attentivement ce qu’elle dit. Si elle n’a pas compris quelque chose de clair, ce n’est probablement pas parce qu’elle n’est pas très brillante.
Il est plus probable que vous n’ayez pas été très clair. (Allez-y et inversez les rôles en lisant ses tests!)
