La pyramide de tests est un modèle pour distribuer les tests sur trois couches. De nombreux tests unitaires rapides à la base, un ensemble plus petit de tests d'intégration au milieu, et peu de tests E2E lents au sommet.

Le modèle original

Mike Cohn a introduit la pyramide de tests en 2009. La version originale avait trois couches :

        /\
       /  \
      / E2E \       ← peu, lents, coûteux
     /--------\
    / Intégration\  ← quelques-uns
   /--------------\
  /  Tests Unitaires\ ← nombreux, rapides, peu coûteux
 /--------------------\

Tests unitaires (bas) : testent des fonctions ou classes individuelles en isolation. Quelques millisecondes pour s'exécuter. Des centaines ou des milliers. Retour immédiat. Tests d'intégration (milieu) : testent comment les composants fonctionnent ensemble, une couche service appelant une base de données, un endpoint API avec un vrai middleware. Quelques secondes pour s'exécuter. Des dizaines à des centaines. Tests E2E (haut) : testent l'ensemble du système via un navigateur ou un client API. Des minutes pour exécuter une suite complète. Des dizaines à quelques centaines.

La forme compte : nombreux en bas, moins en haut. La pyramide.

Pourquoi la forme importe

Si vous inversez la pyramide, de nombreux tests E2E et peu de tests unitaires, vous obtenez :

  • Une suite lente (les tests E2E prennent 10 à 60 fois plus de temps que les tests unitaires)
  • Des tests flaky (plus de parties mobiles = plus de modes d'échec)
  • Une mauvaise information de débogage (un échec E2E dit que quelque chose ne va pas ; un échec de test unitaire dit exactement quoi)
  • Une maintenance coûteuse (les changements UI cassent les tests E2E ; les API changent moins souvent)

L'anti-pattern classique est le cône de glace : une petite couche de tests unitaires, pas de couche d'intégration, et une énorme suite E2E. Cette suite prend 45 minutes à s'exécuter et échoue aléatoirement.

L'interprétation moderne

La pyramide originale est antérieure aux microservices, au serverless, et aux frameworks comme Playwright qui rendent les tests E2E significativement plus fiables. La version moderne reconnaît cela :

        /\
       /  \
      / E2E \          ← smoke tests, chemins critiques
     /--------\
    / API/Svc  \       ← intégration, tests de contrat
   /--------------\
  / Composant/Unit \ ← logique métier, utilitaires
 /------------------\

Les proportions spécifiques varient selon l'équipe et le type de produit. Une API CRUD peut avoir très peu de tests E2E et une forte couverture API. Un tableau de bord React avec une UI complexe peut avoir plus de tests de composants et moins de tests unitaires.

Le principe reste le même : s'appuyer sur les tests moins coûteux, plus rapides et plus stables. Réserver l'E2E pour les scénarios qui ne peuvent être vérifiés qu'à travers la pile complète.

Appliquer la pyramide à un projet Playwright

Ce qui appartient aux tests E2E :
  • Les parcours utilisateur critiques (connexion → checkout → confirmation)
  • L'intégration cross-service (frontend + backend + base de données ensemble)
  • Les comportements spécifiques au navigateur (upload de fichier, multi-onglets, redirection OAuth)
  • Les smoke tests pour les déploiements en production
Ce qui n'appartient pas aux tests E2E :
  • Les messages d'erreur de validation (les tester dans les tests unitaires de la logique de validation)
  • Chaque cas limite d'un algorithme complexe (test unitaire)
  • Les réponses API en isolation (test API)
  • Les 15 permutations d'un formulaire (partitionnement par équivalence, choisir 3 à 4 cas représentatifs pour l'E2E)

Un exemple concret

Vous testez une fonctionnalité de passage de commande. Les exigences :

1. L'utilisateur ajoute un article au panier

2. L'utilisateur va au checkout

3. L'utilisateur remplit les informations de livraison

4. L'utilisateur paye

5. Confirmation de commande affichée

6. E-mail envoyé à l'utilisateur

Les tests unitaires couvrent :
  • La logique de calcul de prix (remises, taxes, frais de livraison)
  • Le rendu du modèle d'e-mail
  • La fonction de validation d'adresse
  • L'arrondi du montant de paiement
Les tests API / d'intégration couvrent :
  • POST /orders crée un enregistrement en base de données
  • POST /orders avec un paiement invalide retourne 422
  • Les transitions de statut de commande (en attente → confirmée → expédiée)
  • Le service d'e-mail appelé avec les bons paramètres
Les tests E2E couvrent : le chemin nominal (commande du panier à la confirmation), l'échec de paiement (carte refusée, commande non créée) et la rupture de stock (article indisponible, utilisateur redirigé).

C'est tout. Trois tests E2E pour une fonctionnalité de checkout entière. Les tests unitaires et API couvrent les cas limites : l'E2E couvre les flux qui comptent le plus pour les utilisateurs.

Le trophée de tests (modèle alternatif)

Kent C. Dodds a proposé le trophée de tests en 2018, qui ajuste la pyramide pour les frontends JavaScript :

          /\
         /  \          ← E2E (peu)
        /----\
       / Intég \       ← intégration (la plupart)
      /----------\
     /  Unitaires \    ← unitaires (quelques-uns)
    /--------------\
   /    Statiques   \  ← types, linting (toujours)
  /------------------\

La différence clé : les tests d'intégration au sommet du milieu. Pour les applications React/Vue/Next.js, "tests d'intégration" signifie rendre des composants avec leurs vraies dépendances (vrais appels API vers un serveur de test, ou une version mockée au niveau réseau). C'est la philosophie de React Testing Library. Elle consiste à tester comment les utilisateurs interagissent avec le composant, pas les détails d'implémentation.

Les deux modèles sont valides. La pyramide s'applique bien aux systèmes backend. Le trophée convient aux applications à forte prédominance frontend. Les deux valent mieux que le cône de glace.

La règle pratique

Quand vous êtes sur le point d'écrire un test E2E, demandez-vous : que vérifie réellement ce test qui ne pourrait pas être vérifié à un niveau inférieur ?

Si la réponse est "que le frontend et le backend sont connectés et que les données circulent correctement à travers toute la pile" : écrivez le test E2E.

Si la réponse est "que la validation du formulaire affiche une erreur pour un champ e-mail vide", un test unitaire et un test de composant font le travail. Le test E2E ne serait que du bruit.

→ See also: Tests de Fumée vs Tests de Régression: Quelle est la Différence? | Tests de Composants avec Playwright: Tester les Composants React/Vue en Isolation | Bonnes Pratiques d'Automatisation de Tests qui Comptent Vraiment