La pyramide des tests
Les trois niveaux de test, du test unitaire au test de bout en bout, la forme de pyramide qui répartit leur nombre, leur durée et la précision de leur diagnostic, et le cornet de glace qu'il faut éviter.
- 23 cartes
- 5 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Sur la frise
- Mises en situation
Quelques cartes du deck
Test unitaire : de quoi s'agit-il ?
Voir la réponse
Test qui vérifie une petite unité de code (une fonction, une méthode, une classe) isolée du reste de l'application.
Sans base de données, sans réseau, sans interface, il s'exécute en quelques millisecondes ; quand il échoue, la faute est dans l'unité testée.
Pourquoi limite-t-on le nombre de tests de bout en bout ?
- Lents et fragiles, ils désignent mal la faute quand ils échouent
- Ils ne vérifient pas ce que voit l'utilisateur, seulement le code interne
- Ils refont ce que vérifient déjà les tests unitaires et ne trouvent rien de plus
- Ils ne peuvent pas être automatisés et doivent toujours être joués à la main
Voir la réponse
Lents et fragiles, ils désignent mal la faute quand ils échouent
Un test de bout en bout vérifie bien ce que voit l'utilisateur, il s'automatise (navigateur piloté) et il trouve des fautes qu'aucun test unitaire ne voit, comme un parcours rompu entre deux écrans. Son défaut est le coût : lenteur, instabilité, diagnostic flou. On en garde donc quelques-uns, sur les parcours essentiels.
Dans la pyramide des tests, la … regroupe les tests unitaires, les plus nombreux, et le … les tests de bout en bout, les moins nombreux.
Voir la réponse
Dans la pyramide des tests, la base regroupe les tests unitaires, les plus nombreux, et le sommet les tests de bout en bout, les moins nombreux.
Les tests de la base coûtent peu à écrire, à lancer et à maintenir : on peut en avoir des milliers. Ceux du sommet coûtent cher : on les réserve aux parcours essentiels.
Test d'intégration : de quoi s'agit-il ?
Voir la réponse
Test qui vérifie que plusieurs modules, ou un module et une ressource réelle comme une base de données, fonctionnent ensemble.
Il trouve les fautes que les tests unitaires ne voient pas, celles des interfaces : mauvais format, mauvaise unité, colonne mal nommée. Il est plus lent, parce qu'il fait travailler de vrais composants.
Une suite compte 40 tests unitaires et 600 tests de bout en bout. Elle dure 2 heures et échoue au hasard. Quelle est la cause principale ?
- Une pyramide inversée : l'essentiel repose sur des tests lents et fragiles
- Les tests unitaires sont trop nombreux et ralentissent les tests de bout en bout
- Le serveur d'intégration continue est sous-dimensionné : une machine plus puissante réglerait tout
- Les tests de bout en bout ne sont pas assez nombreux pour couvrir l'application
Voir la réponse
Une pyramide inversée : l'essentiel repose sur des tests lents et fragiles
Six cents tests qui pilotent le navigateur, la base et le réseau durent longtemps et échouent au gré des attentes et de l'état des données. Une machine plus puissante raccourcirait un peu la durée, mais pas les échecs au hasard : le problème est la forme de la suite.