Module 01 · Les bases du test · 10 min
Le bon niveau de test
Composant, intégration, système : tester chaque comportement au niveau le plus bas qui peut le prouver, et savoir quels comportements aucun d'eux ne prouve.
Révision
De la leçon précédente : la règle accepte de 20 à 2 000 caractères. Quelles longueurs un test de limites essaie-t-il, et pourquoi tester 500 ne suffit-il pas ?
La réponse du cours
19, 20, 2 000 et 2 001 : chaque limite et la première valeur de chaque côté. 500 est au milieu de la classe valide ; un < écrit à la place de <= passerait à 500 et n'échouerait que sur la limite.
Trois niveaux
| Niveau | Prouve | Ce que le test touche |
|---|---|---|
| Composant (unitaire) | La logique d'une unité : un calcul, une validation, une correspondance | Une fonction ou un module, en mémoire, tout ce qui l'entoure remplacé |
| Intégration | Deux vraies parties s'accordent : ClaimTriage et le système des sinistres, le code et sa base de données | La jonction entre deux parties nommées |
| Système | Le produit assemblé respecte le critère de bout en bout | Le produit déployé, par son vrai écran, sa vraie API ou sa vraie connexion |
La règle : tester chaque comportement au niveau le plus bas qui peut le prouver. On ne monte que si le comportement n'existe pas plus bas.
Un test de composant tourne en quelques millisecondes et dit au développeur exactement quelle fonction est fausse. Un test système prend des secondes ou des minutes, demande un environnement et des données, et quand il échoue, la cause peut être n'importe où. Tester la table de routage à travers l'écran ne prouve rien de plus qu'un test de composant, dix mille fois plus lentement.
Pour placer un comportement, posez ces questions dans l'ordre, et arrêtez-vous au premier oui :
- Le code de l'unité, seul, peut-il en décider, ses entrées maîtrisées ? Composant.
- Dépend-il de la façon dont deux vraies parties s'accordent (un schéma, un protocole, une panne d'un côté) ? Intégration, sur cette jonction seulement.
- N'existe-t-il qu'une fois le produit assemblé et déployé (authentification unique, droits appliqués par la plateforme, parcours utilisateur) ? Système.
Ce qui n'est pas un niveau
La recette n'est pas un quatrième niveau. C'est une décision du métier que le produit fait le travail, prise par les personnes qui l'utiliseront. Elle s'ajoute aux trois niveaux, elle n'en remplace aucun.
Certains comportements, aucun niveau ne les prouve. Le résumé en deux phrases de ClaimTriage a beaucoup de formulations acceptables : aucune assertion ne peut le comparer à une phrase attendue. C'est le sujet de la partie 2 de ce cours. Le reconnaître dès maintenant compte, parce que l'erreur classique est de le tester quand même par une comparaison exacte, et de faire échouer toute bonne réponse formulée autrement.
Six comportements
Un développeur teste la règle de longueur au niveau composant, et le testeur ajoute les mêmes quatre longueurs à travers l'écran « pour être sûr ». Que prouve la seconde série ?
La réponse du cours
Rien de nouveau, pour un coût bien plus élevé. La règle est la logique propre de l'unité, et les tests de composant la prouvent déjà sur les quatre longueurs. Passées par l'écran, les mêmes longueurs prouvent que l'écran appelle la règle, ce qu'un seul cas système montre aussi bien.
Un comportement testé à deux niveaux doit y prouver deux choses différentes. La même assertion répétée plus haut ajoute de la lenteur, et un second endroit à maintenir.
| A | Rien de nouveau sur la règle ; un cas système suffit à montrer que l'écran l'utilise | ✅ |
| B | « C'est plus sûr de tester deux fois » | ⚠️ Plus sûr seulement si le second test prouve quelque chose que le premier ne peut pas |
| C | « Les tests système sont les vrais tests » | ❌ Ce sont les plus lents et les moins précis. Ils sont faits pour ce qui n'existe qu'une fois assemblé |