Test end-to-end (E2E)

Un test end-to-end (E2E, de bout en bout) sollicite le système comme le ferait un utilisateur, avec toutes les couches réelles : navigateur, front-end, services back-end, base de données, files de messages et, quand c’est faisable, intégrations tierces. Il répond à la question à laquelle les niveaux inférieurs ne peuvent pas répondre : l’ensemble fonctionne-t-il réellement pour un vrai parcours ? Les tests E2E sont au sommet de la pyramide des tests, car ils apportent la confiance la plus réaliste au coût le plus élevé.

Exemple (Playwright)

import { test, expect } from '@playwright/test';

test('guest can buy a product', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('searchbox', { name: 'Search' }).fill('desk lamp');
  await page.keyboard.press('Enter');
  await page.getByRole('link', { name: 'Desk Lamp' }).click();
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.getByRole('link', { name: 'Checkout' }).click();
  await page.getByLabel('Email').fill('guest@example.com');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByRole('heading', { name: 'Thank you for your order' })).toBeVisible();
});

Un seul test traverse les services de recherche, de catalogue, de panier, de paiement et de commande. Si le service panier sérialise mal les prix, ce test le détecte même lorsque tous les tests unitaires de chaque service passent.

Pourquoi en garder peu

• Lents. De quelques secondes à quelques minutes chacun, contre quelques millisecondes pour les tests unitaires.
• Sujets à l’instabilité (flakiness). Plus de pièces en mouvement signifie plus de problèmes de timing, de données partagées et d’instabilité d’environnement.
• Diagnostic difficile. « Le paiement a échoué » peut venir de n’importe lequel d’une dizaine de services.
• Coûteux à maintenir. Les changements d’UI se répercutent sur de nombreux tests.

Réservez donc les tests E2E aux parcours métier critiques, comme l’inscription, l’achat et les workflows clés, et couvrez les variantes (chaque règle de validation, chaque type de remise) aux niveaux unitaire et API.

Les rendre fiables

• Utilisez des attentes basées sur des conditions, comme l’auto-waiting et les assertions web-first de Playwright ou le WebDriverWait de Selenium, jamais de pauses fixes.
• Créez les données de test via des API dans la phase de préparation au lieu de cliquer dans l’UI, et donnez à chaque test ses propres données.
• Utilisez des locators stables : rôles, labels et test IDs plutôt que des XPath dépendants de la mise en page.
• Structurez le code avec des page objects ou un équivalent, pour qu’un changement d’UI se corrige à un seul endroit.

« End-to-end » et « test système » se recoupent : le test système est un niveau de test, tandis que E2E décrit le style de test qui traverse toutes les couches.