La pyramide de tests : quel test appartient à quel niveau

Ce que c'est

Selon l'entrée du bliki de Fowler, la pyramide de tests est devenue connue surtout grâce à Mike Cohn, qui l'a décrite en 2009 dans « Succeeding with Agile ». Elle organise les tests automatisés en niveaux : en bas, de nombreux tests unitaires, qui vérifient une unité de façon isolée et en quelques millisecondes ; au milieu, des tests d'intégration, qui font intervenir de vrais voisins tels que la base de données ou le système de fichiers ; en haut, quelques tests de bout en bout, qui sollicitent tout le système via son interface publique. Vers le haut augmentent le coût et le temps d'exécution, vers le bas la précision et la rapidité. Fowler nomme la forme inversée — une grosse tête de tests de surface, presque pas de base — le cornet de glace (« ice-cream cone »). L'article « The Practical Test Pyramid » du même site parcourt les niveaux sur l'exemple d'un microservice.

Pourquoi c'est important

Chaque niveau échange de la proximité avec la réalité contre du pouvoir diagnostique. Un test unitaire échoué désigne la fonction, un test de bout en bout échoué désigne le système et ne fait que lancer la recherche. Les suites comportant trop de tests lents s'exécutent rarement, deviennent plus instables et finissent par être ignorées peu à peu ; la pyramide maintient un retour assez rapide pour que développeurs et agents testent après chaque petite modification.

Comment l'appliquer

• Placer la logique dans des unités vérifiables sans infrastructure (fonctions pures, classes à dépendances injectées), et les tester de façon exhaustive à la base, y compris les cas limites et d'erreur.
• Vérifier les points de jonction — requêtes, gestionnaires HTTP, sérialisation, files d'attente — au milieu, face à de vraies dépendances en conteneurs, et non face à des simulacres de la base de données.
• Ne tester de bout en bout que les quelques parcours dont l'échec touche l'activité (connexion, achat, export), et ce sur la branche d'intégration plutôt qu'à chaque commit.
• Si un test de bout en bout échoue, reproduire en plus la même erreur avec un test de niveau inférieur, qui la détectera plus vite à l'avenir.
• Surveiller le temps d'exécution de la base ; s'il dépasse quelques secondes, il vaut la peine de chercher des tests d'intégration déguisés en tests unitaires.

Pièges

Des tests unitaires qui remplacent tout par des simulacres ne vérifient que les simulacres. Des tests d'intégration à état mutable partagé deviennent dépendants de l'ordre d'exécution. La pyramide décrit des proportions, pas des quantités absolues ; un petit service peut être plat tout en étant bien testé. Fowler lui-même note que l'hypothèse « les tests larges sont coûteux, lents et fragiles » est vraie la plupart du temps, mais pas toujours.