Testing E2E: perché dovresti iniziare con Playwright

Quando hai bisogno di testare la tua applicazione web, i test unitari sono spesso la prima linea di difesa. Ma cosa succede quando gli utenti iniziano a lamentarsi di bug che i tuoi test non hanno mai catturato?

Il gap che nessun unit test può colmare

I test unitari dicevano che andava tutto bene, eppure le lamentele degli utenti continuavano ad arrivare.

Mancava un tassello: non ci siamo immedesimati negli utenti. Ci siamo focalizzati sulla copertura della codebase, non su cosa gli utenti sperimentano quando usano il prodotto.

Questo è esattamente il gap che il testing End-to-End (E2E) punta a colmare.

Cos’è il Testing E2E

Il testing E2E simula il comportamento di un utente reale: apre un browser, naviga le pagine, clicca sui bottoni, compila form, e verifica che tutto funzioni come previsto.

A differenza dei test unitari (che testano singole funzioni) o dei test di integrazione (che verificano la comunicazione tra moduli), i test E2E validano l’intera applicazione dal punto di vista dell’utente finale.

Vantaggi

• Confidenza: Stai testando esattamente ciò che l’utente sperimenta utilizzando l’applicazione
• Copertura reale: Verifichi l’integrazione di frontend, backend, database e servizi esterni
• Protezione del business: I flussi critici (login, checkout, pagamenti) sono garantiti come funzionanti

Perché molti team li evitano

I test E2E fanno paura. E non senza motivo.

“Richiedono tempo”: C’è la percezione che scrivere test E2E sia un investimento enorme, tempo sottratto allo sviluppo di feature. E in effetti, se l’approccio è sbagliato, lo è.

“Sono difficili da manutenere”: L’interfaccia cambia, i test si rompono, nessuno ha voglia di sistemarli. Diventano quel task che si rimanda sempre.

“Non sappiamo da dove iniziare”: Quali flussi testare? Come strutturare i test? Dove metterli nella pipeline? L’assenza di una strategia chiara paralizza.

“Abbiamo già i test unitari”: Il senso di sicurezza dato da una elevata copertura degli unit test. Se il codice è testato, l’applicazione funziona. Giusto?

Il risultato? Molti team non iniziano mai, oppure abbandonano dopo i primi tentativi falliti.

Ma gli strumenti sono cambiati. E con loro, le regole del gioco.

Playwright: Un cambio di paradigma

Playwright, sviluppato da Microsoft, non è solo un altro framework di testing: è un ripensamento completo di come dovrebbero funzionare i test E2E. Uno dei principali di fattori di successo sta nella sua integrazione con linguaggi come JavaScript/TypeScript, Python, C# e Java, e con browser moderni come Chromium, Firefox e WebKit.

I tre pilastri

1. Affidabilità (meccanismo di auto-waiting)

Playwright aspetta automaticamente che gli elementi siano visibili, stabili e interattivi prima di agire:

await page.getByRole('button', { name: 'Acquista' }).click();

Playwright sa quando l’elemento è pronto. Se il bottone appare dopo 100ms o dopo 2 secondi, non importa: il test funziona in entrambi i casi.

2. Velocità (Parallelizzazione nativa)

I test girano in parallelo con isolamento completo. Ogni test ha il suo browser context, eliminando interferenze tra test.

3. Semplicità (Developer Experience)

Una singola API per Chromium, Firefox e WebKit. Setup in un comando:

npm init playwright@latest

E strumenti che rendono il debugging (quasi) un piacere invece che un incubo.

Gli strumenti che fanno la differenza

Codegen: Registra, non scrivere

npx playwright codegen tuosito.com

Playwright registra le tue azioni nel browser e genera il codice corrispondente. Perfetto per iniziare rapidamente o per flussi complessi.

UI Mode: Debugging visuale

npx playwright test --ui

Un’interfaccia grafica dove puoi eseguire test singolarmente, vedere lo stato del DOM in ogni step, e ispezionare cosa è andato storto.

Trace Viewer: L’autopsia dei test falliti

Quando un test fallisce in CI, il Trace Viewer ti mostra esattamente cosa è successo: screenshot, network requests, console logs, DOM snapshots. Tutto in un unico file che puoi aprire nel browser.

Un primo test concreto

In questo esempio, un utente visita il sito di un e-commerce, cerca un prodotto, lo aggiunge al carrello, e verifica che il carrello mostri il numero corretto di articoli.

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

test('utente completa un acquisto', async ({ page }) => {
  // Naviga alla home
  await page.goto('https://shop.example.com');

  // Cerca un prodotto
  await page.getByPlaceholder('Cerca prodotti...').fill('laptop');
  await page.getByRole('button', { name: 'Cerca' }).click();

  // Aggiungi al carrello
  await page.getByTestId('product-card').first().click();
  await page.getByRole('button', { name: 'Aggiungi al carrello' }).click();

  // Verifica
  await expect(page.getByTestId('cart-count')).toHaveText('1');
});

Nota come i selettori siano semantici: getByRole, getByPlaceholder, getByTestId. Questo rende i test resistenti ai cambiamenti di stile e struttura HTML.

Quando usare i test E2E

I test E2E non sostituiscono unit e integration test. La piramide dei test resta valida: molti unit test veloci alla base, meno integration test al centro, pochi E2E mirati in cima.

Usa i test E2E per:

• Flussi critici di business (registrazione, checkout, pagamenti)
• Smoke test dopo ogni deploy
• Regressioni su funzionalità core

Non usarli per:

• Testare ogni edge case (per quello, esistono gli unit test)
• Validare logica di business isolata
• Coprire il 100% del codice

Errori da evitare

Un paio di trappole comuni quando si inizia:

• Selettori fragili. Evita CSS selector legati alla struttura HTML o alle classi di stile. Cambiano spesso e rompono i test. Preferisci getByRole, getByLabel, getByTestId, utilizzando attributi data-testid dedicati.

• Test che dipendono l’uno dall’altro. Ogni test deve poter girare in isolamento. Se il test B fallisce perché il test A non ha preparato i dati, hai un problema di design.

• Testare troppo. Non serve coprire ogni flusso con E2E. Concentrati sui percorsi critici e lascia gli edge case agli unit test.

Inizia oggi

Se non hai mai scritto test E2E, o se li hai abbandonati per frustrazione, Playwright merita una seconda chance. La curva di apprendimento è sorprendentemente dolce, e i benefici sono immediati.

# Tutto quello che serve per iniziare
npm init playwright@latest
npx playwright test

Il tuo futuro te stesso, il tuo team, e i tuoi utenti ti ringrazieranno la prossima volta che un deploy andrà liscio.

Risorse utili:

• Documentazione ufficiale
• Getting Started
• GitHub