Module 01 · Les bases du test · 15 min
Une suite verte sur un bogue
Quinze minutes, rien à installer. Vous lancez une vraie suite de tests, vous la voyez passer sur un produit qui se trompe, et vous découvrez d'où ses résultats attendus auraient dû venir.
Pas de théorie pour l'instant. Vous allez d'abord lancer quelque chose, et la théorie passera mieux une fois que vous l'aurez vu.
1. Le produit, et sa suite de tests
ClaimTriage est un assistant utilisé par les conseillers d'un assureur. Un conseiller colle la déclaration de sinistre d'un client et reçoit une fiche de tri, avec la file vers laquelle envoyer le sinistre. Le manuel d'exploitation contient la table de routage :
| Urgence | File |
|---|---|
critical |
queue-A, quelle que soit la ligne de produit |
standard ou priority |
la file de la ligne de produit : queue-motor, queue-property, queue-travel, queue-liability |
Le développeur qui a écrit le routage a aussi écrit sa suite de tests : huit sinistres, et pour chacun la file qu'il doit atteindre. Pour remplir les files attendues, il a lancé le service et recopié ce qu'il renvoyait. La suite est verte depuis.
La suite ci-dessous est celle-là, lancée par le moteur du cours dans votre navigateur. Chaque cas vérifie une seule chose : la file. Lisez le manifest si vous le voulez, mais ne changez rien pour l'instant. Prédisez le verdict, et combien de cas échoueront. Puis lancez-la.
La suite de routage de ClaimTriage
8 cas, mock-triage-service 2.3.0, une assertion par cas sur la file. Le moteur tourne dans votre navigateur.
Choisissez une prédiction pour lancer l'évaluation.
2. Regardez ce qui est passé
Pass, huit cas sur huit. Ouvrez maintenant les files attendues auxquelles la suite a comparé le service :
| Cas | Ligne de produit | Urgence | Attendu dans la suite |
|---|---|---|---|
| R-01 | motor | standard | queue-motor |
| R-02 | motor | critical | queue-A |
| R-03 | property | standard | queue-property |
| R-04 | property | priority | queue-property |
| R-05 | travel | standard | queue-travel |
| R-06 | travel | critical | queue-travel |
| R-07 | liability | critical | queue-liability |
| R-08 | liability | priority | queue-liability |
Comparez ce tableau à la table de routage plus haut. Avant de lire la suite, trouvez les cas où les deux ne sont pas d'accord.
3. Lancez-la contre la spécification
La table de routage est la spécification : l'équipe d'exploitation en est propriétaire, et elle dit ce que le produit doit faire. Un second fichier, routing-spec.jsonl, contient les mêmes huit cas, avec des files attendues tirées de cette table et non du service.
Dans le manifest ci-dessous, changez une ligne, pour que le jeu de cas soit :
evaluation_data:
path: routing-spec.jsonl
Vous avez trouvé les désaccords à l'étape 2 : prédisez le verdict et le nombre de cas en échec, puis lancez.
La suite de routage de ClaimTriage
8 cas, mock-triage-service 2.3.0, une assertion par cas sur la file. Le moteur tourne dans votre navigateur.
Choisissez une prédiction pour lancer l'évaluation.
4. Ce qui a changé, et ce qui n'a pas changé
Fail, avec deux assertions en échec : R-06 et R-07. Un sinistre voyage critique part dans la file voyage, un sinistre de responsabilité civile critique dans la file responsabilité civile. Deux personnes hospitalisées, qui attendent dans une file ordinaire au lieu de celle qui est organisée pour les urgences.
Le produit n'a pas changé entre les deux exécutions. Les cas de test non plus, ni les assertions. Une seule chose a changé : l'origine des résultats attendus.
- Recopiés depuis le service, ils décrivent ce que le code fait. Une suite écrite ainsi passe sur tous les bogues que le code a déjà, et n'échoue que le jour où quelqu'un en corrige un.
- Tirés de la table de routage, ils décrivent ce que le produit doit faire. C'est la seule version qui peut attraper un défaut.
Un test compare ce que fait le produit à ce que quelqu'un a décidé qu'il devait faire. Si personne n'a décidé, il n'y a rien à quoi comparer, et le résultat attendu honnête n'est pas une supposition : c'est « à confirmer », avec le nom de la personne qui décide.
Le développeur dit : « la suite était verte depuis trois mois, donc le routage est bon. » Répondez-lui, en deux phrases, sans accuser personne.
La réponse du cours
La suite comparait le service à lui-même : ses files attendues ont été recopiées depuis ce que le service renvoyait, donc elle ne pouvait que passer. Avec les files tirées de la table de routage du manuel d'exploitation, les mêmes huit cas échouent sur R-06 et R-07 : les sinistres voyage et responsabilité civile critiques partent dans la mauvaise file depuis le début.
Ce qui compte est le mécanisme, pas le coupable. Recopier les résultats attendus depuis la sortie est un raccourci courant, et il transforme un test en enregistrement.
| Vous avez écrit quelque chose comme | ||
|---|---|---|
| A | Les résultats attendus ont été recopiés depuis le code, donc la suite ne pouvait pas échouer ; avec la table de routage, elle échoue sur R-06 et R-07 | ✅ |
| B | « Des tests verts ne prouvent rien » | ⚠️ Trop large. Des tests verts prouvent beaucoup quand leurs résultats attendus viennent d'une spécification |
| C | « Le développeur aurait dû être plus attentif » | ❌ Peut-être vrai, et inutile : cela ne dit pas quoi changer dans la suite |
Deux exécutions, et la première règle de ce cours : un test vaut ce que vaut son résultat attendu. La leçon suivante part de l'endroit d'où viennent les résultats attendus : un critère qu'on peut tester.