Les tests automatisés, expliqués simplement
Un test, c’est un contrôle qu’on écrit une fois et que la machine refait à chaque changement. Voilà comment on sait qu’une modification n’a rien cassé ailleurs.
En une image
Pensez à la liste de vérification d’un pilote avant le décollage. Elle est écrite, elle est la même à chaque vol, et personne ne décolle sans l’avoir parcourue. Les tests sont cette liste, sauf que c’est l’ordinateur qui la parcourt, en quelques secondes, à chaque changement du logiciel.
Ce qu’il faut retenir
-
Écrits à partir de ce que vous avez demandé
Chaque exigence devient un contrôle : « une commande confirmée crée sa livraison ». Si ce n’est plus vrai un jour, le contrôle le dit, avant que quelqu’un s’en plaigne.
-
Un bug, d’abord un contrôle
Avant de corriger un défaut, on écrit le contrôle qui l’attrape. Une fois corrigé, le défaut ne peut plus revenir sans se faire voir.
-
Un contrôle qui ne peut pas échouer ne sert à rien
On ne tord jamais un contrôle pour le faire passer : si c’est rouge, c’est le logiciel qu’on corrige. Un contrôle toujours vert, quoi qu’il arrive, est un défaut.
-
Refait à chaque changement, relu par quelqu’un d’autre
Un serveur rejoue tous les contrôles à chaque envoi de code. Et avant qu’un changement n’entre, quelqu’un qui ne l’a pas écrit le relit.
Un exemple : un bug signalé
Quatre étapes, toujours dans cet ordre.
-
On l’attrape
Un contrôle reproduit le défaut, tel que vous l’avez décrit.
-
Il est rouge
La preuve que le contrôle voit bien le défaut.
-
On corrige
Le logiciel change, le contrôle passe au vert.
-
Il reste vert
Le contrôle est rejoué à chaque changement : le défaut ne revient pas sans être vu.
Pour aller plus loin
-
Les tests automatisés, expliqués aux développeurs
Les règles, un bug pris en quatre étapes et un test de dix lignes, pour qui débute avec Odoo.
Une question ?
Je réponds aussi aux curieux : écrivez-moi.