Test end-to-end (E2E)

Un test end-to-end (E2E) mette alla prova il sistema come farebbe un utente, con ogni livello reale: browser, front end, servizi di back end, database, code di messaggi e, dove possibile, integrazioni di terze parti. Risponde alla domanda a cui i livelli inferiori non possono rispondere: tutto quanto funziona davvero insieme in un percorso reale? I test E2E stanno in cima alla piramide dei test perché danno la fiducia più realistica al costo più alto.

Esempio (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 solo test attraversa i servizi di ricerca, catalogo, carrello, checkout e ordini. Se il servizio del carrello serializza male i prezzi, questo test lo intercetta anche quando passano tutti i test unitari di ogni servizio.

Perché tenerne pochi

• Lenti. Da secondi a minuti ciascuno, contro i millisecondi dei test unitari.
• Inclini all’instabilità (flaky). Più parti in movimento significano più problemi di tempistica, dati condivisi e ambienti instabili.
• Diagnosi difficile. “Il checkout è fallito” potrebbe dipendere da una dozzina di servizi diversi.
• Costosi da mantenere. Le modifiche alla UI si propagano su molti test.

Riserva quindi i test E2E ai percorsi di business critici, come registrazione, acquisto e flussi principali, e copri le varianti (ogni regola di validazione, ogni tipo di sconto) ai livelli unitario e API.

Renderli affidabili

• Usa attese basate su condizioni, come l’auto-waiting e le asserzioni web-first di Playwright o il WebDriverWait di Selenium, mai pause fisse.
• Crea i dati di test tramite API nel setup invece di cliccare nella UI, e dai a ogni test i propri dati.
• Usa locator stabili: ruoli, label e test ID invece di XPath dipendenti dal layout.
• Struttura il codice con i page object o qualcosa di simile, così che una modifica alla UI si corregga in un solo punto.

“End-to-end” e “test di sistema” si sovrappongono: il test di sistema è il livello di test, mentre E2E descrive lo stile di test che attraversa tutti i livelli.