Pyramide des tests¶

Comprendre les niveaux de test, le compromis coût/confiance et les anti-patterns courants.

Le modèle de la pyramide¶

La pyramide des tests, proposee par Mike Cohn, organisé les tests en trois niveaux selon leur coût et leur portee.

graph TB
    E2E["E2E<br/>Peu nombreux<br/>Lents, fragiles, haute confiance"]
    INT["Integration<br/>Moderement nombreux<br/>Vitesse et portee intermediaires"]
    UNIT["Unitaires<br/>Tres nombreux<br/>Rapides, isoles, faible portee"]

    E2E --- INT
    INT --- UNIT

    style E2E fill:#ef5350,color:#fff
    style INT fill:#ff9800,color:#fff
    style UNIT fill:#4caf50,color:#fff

Niveau	Quantite	Vitesse	Portee	Fragilite
Unitaire	Beaucoup	Très rapide	Une fonction/classe	Faible
Intégration	Moyen	Moyen	Plusieurs composants	Moyenne
E2E	Peu	Lent	Le système complet	Élevée

Le principe¶

La base est large : beaucoup de tests unitaires rapides et fiables
Le milieu valide que les composants fonctionnent ensemble
Le sommet vérifié le parcours utilisateur de bout en bout

La règle du 70/20/10

Un ratio souvent cite : 70% unitaires, 20% intégration, 10% E2E. Ce n'est pas une loi — c'est un point de départ. Adaptez selon votre contexte.

Les anti-patterns¶

Le cornet de glace (Ice Cream Cone)¶

La pyramide inversee : beaucoup de tests E2E, peu de tests unitaires.

graph TB
    UNIT2["Unitaires<br/>Presque aucun"]
    INT2["Integration<br/>Quelques-uns"]
    E2E2["E2E<br/>La majorite"]

    UNIT2 --- INT2
    INT2 --- E2E2

    style E2E2 fill:#ef5350,color:#fff
    style INT2 fill:#ff9800,color:#fff
    style UNIT2 fill:#4caf50,color:#fff

Conséquences :

Suite de tests très lente (30+ minutes)
Tests fragiles — cassent pour des raisons non liees au code (timeout, service externe down)
Feedback lent — le développeur apprend qu'il a casse quelque chose 30 minutes après
Personne ne lance les tests en local → détection en CI uniquement

Le sablier¶

Beaucoup de tests unitaires, beaucoup de tests E2E, mais aucun test d'intégration. Les unitaires passent (chaque composant fonctionne seul), les E2E sont fragiles, et personne ne teste les interfaces entre composants.

Le trophee (Testing Trophy)¶

Propose par Kent C. Dodds comme alternative à la pyramide pour les applications frontend :

graph TB
    E2ET["E2E"]
    INTT["Integration ← la majorite"]
    UNITT["Unitaires"]
    STATIC["Analyse statique"]

    E2ET --- INTT
    INTT --- UNITT
    UNITT --- STATIC

    style INTT fill:#ff9800,color:#fff

L'idée : en frontend, les tests d'intégration (composant rendu dans un DOM virtuel, interactions simulees) offrent le meilleur ratio confiance/coût. Les tests unitaires purs testent souvent des détails d'implémentation.

Pyramide ou trophee ?

La pyramide reste le modèle de référence pour le backend et les systèmes distribués. Le trophee est pertinent pour le frontend ou l'interaction entre composants est le sujet principal.

Qu'est-ce qu'un bon test¶

Un bon test possédé ces propriétés — acronyme FIRST :

Propriété	Signification
Fast	S'exécuté en millisecondes, pas en secondes
Isolated	Ne dépend d'aucun autre test, ni de l'ordre d'exécution
Repeatable	Même résultat à chaque exécution, sur n'importe quelle machine
Self-validating	Pass ou fail — pas besoin d'inspection manuelle
Timely	Écrit au bon moment (idealement avant le code — voir TDD)

Le contrat de test¶

Chaque test vérifié un comportement, pas une implémentation :

GIVEN un contexte initial
WHEN une action se produit
THEN un resultat est observe

Ce pattern (Arrange/Act/Assert ou Given/When/Then) rend les tests lisibles et maintenables. Si le test casse parce que vous avez renomme une variable interne, il teste l'implémentation et non le comportement.

Quand écrire quel type de test¶

Situation	Type de test recommande
Logique métier pure (calculs, validations)	Unitaire
Interaction entre services	Intégration
Requête SQL / accès base de données	Intégration
API HTTP (controller + service + DB)	Intégration
Parcours utilisateur complet	E2E
Composant UI isole	Unitaire (component test)
Page avec interactions et navigation	Intégration (DOM virtuel)

Outils¶

Cette page est conceptuelle — les outils spécifiques sont détaillés dans les pages suivantes et dans les tutoriels par langage :