🧟 Toujours savoir quel test écrire grâce aux ZOMBIES !

Plus d'excuse, écrivez vos premiers tests unitaires dès maintenant :)

Cet article fait partie d’un groupe d’articles à propos des tests automatisés. Si vous avez manqué le précédent article, je vous invite à le lire ici : 5 principes pour écrire de meilleurs tests unitaires à mettre en place dès maintenant

Quand on commence à écrire des tests unitaires, et surtout quand on cherche à les écrire avant le code de production, on a besoin d’être guidé.

Dans le dernier article, nous avons vu que les principes auxquels doivent répondre les tests unitaires peuvent se résumer à l’acronyme FIRST :

• Fast 🚀

• Independent 🧪

• Repeatable 🔁

• Self-validating ✅

• Thorough 📦

C’est ce dernier point qui va nous intéresser. Comment s’assurer que nous avons couvert tous les cas possibles ?

Il existe un autre acronyme qui va pouvoir nous guider :)

Laissez-vous guider par les Z.O.M.B.I.E.S

Levons tout de suite le voile sur le contenu de cet acronyme :

• Zero

• One

• Many (ou More complex)

• Boundary behavior

• Interface definition (ou Intention revealing code)

• Exceptional behavior

• Simple Scenarios, Simple Solutions

Cet acronyme se divise en fait en 3 parties :

• S

• BIE

• ZOM

SBIEZOM sonne quand même moins bien que ZOMBIES, mais c’est plus simple de comprendre les différents éléments de cet acronyme en le prenant à l’envers, car ils se composent les uns dans les autres.

Ces trois parties vont en permanence nous aiguiller dans la création de nos tests unitaires.

Voyons comment.

Simple Scenarios, Simple Solutions

L’acronyme Z.O.M.B.I.E.S définit un schéma de pensée à adopter pour être guidé dans les tests à écrire.

Chacun de nos tests, afin d’être compréhensibles et utiles, vont donc devoir utiliser des Scénarios simples, avec des Solutions simples. Autrement dit : KISS (Keep It Stupid Simple).

C'est donc l’objectif de nos tests : créer du code simple, à travers des exemples simples :

Nous ne sommes toujours pas plus avancés pour l’instant pour savoir quels tests écrire !

Voyons si la prochaine partie de l’acronyme nous y aide.

B.I.E : Découvrir l’Interface de notre code, les cas limites et les cas d’erreur

Si le S de ZOMBIES nous oriente vers un objectif pour nos tests, la partie B.I.E nous assure de nous concentrer sur l’intention des tests, toujours dans un objectif de Simplicité.

Lorsque l’on écrit les tests, ceux-ci doivent nous permettre de découvrir “l’Interface” de notre code. C’est-à-dire la façon dont on aimerait pouvoir “appeler” notre code. C’est aussi ce qu’on appelle le wishfull programming.

C’est une pratique très puissante, car cela permet de se focaliser sur l’intention du code. C’est le I de ZOMBIES, pour Interface, mais que moi j’aime bien décrire comme Intention.

Certains comportements vont aussi être à la marge. C’est facile de penser au “happy path”, mais dès que les cas les plus complexes se présentent, on oublie souvent de les tester. C’est le B de ZOMBIES, pour Boundaries Behaviors.

Enfin, le E de ZOMBIES s’assure qu’on teste aussi les cas d’erreurs, les fameux “sad paths”.

B.I.E nous incite donc à écrire du code qui révèle son intention, et dont on teste certains types de comportements. Le tout, “inclus” dans le S comme le souligne le schéma. Donc toujours dans l’objectif d’écrire du code Simple.

Mais on ne sait toujours pas par où commencer !

C’est là qu’intervient le reste de l’acronyme.

Z.O.M : Se laisser guider, pas à pas

Lorsque l’on écrit les tests avant d’écrire le code de production, c’est pour se faire guider pas à pas vers l’implémentation du code, avec un feedback rapide, pour ne jamais se retrouver perdu.

Le Z nous incite donc à tester un comportement dans le cas où il ne se passe “rien”. C’est souvent un état initial par exemple, cela va nous permettre de commencer à faire émerger l’interface de code qu’on souhaite manipuler à travers une intention précise. Il ne faut pas avoir peur d’écrire des valeurs de retour en dur ici.

Le O lui nous incite à créer le premier cas le plus simple, le cas où il y a “un” élément. Ce que veut dire cette notion de “un” élément dépend du contexte du comportement. Généralement on s’attaquera à l’une des valeurs de retour écrites en dur. Pour ce faire, on crée un test Simple qui va nous obliger à écrire de la logique pour supprimer la valeur de retour en dur.

Enfin, le M va tester des cas plus complexes, là encore cela dépend du comportement que vous voulez tester.

Pour résumer

Comme on peut le voir sur le schéma ci-dessus, l’acronyme Z.O.M.B.I.E.S n’est pas à prendre lettre après lettre.

Il se conçoit comme plusieurs sous-ensembles.

Les premières lettres, ZOM, nous aident à définir les premiers tests à écrire.

Ces tests doivent révéler l’Intention (à travers l’interface de code) du code et tester le comportement aux limites (Boundaries Behavior) ou dans les cas d’erreur (Exceptional Behavior).

Le tout, en se concentrant sur des Scénarios simples, et du code sous forme de Solutions simples.

Happy Coding :)

---

Cet article vous a plu ? Vous pouvez me soutenir gratuitement en vous inscrivant à mon programme de parrainage, en échange, je vous offre des bons de réduction valables à vie sur tous les cours (actuels et futurs) de CraftAcademy.fr 🎉