Test end-to-end con Playwright
Dalla flakiness al Page Object Model, nove articoli su una suite di cui fidarsi
Le suite E2E non vengono abbandonate perché sono lente: vengono abbandonate quando il team smette di credere ai loro fallimenti. La serie parte dal motivo tecnico per cui i test flaky esistono: il protocollo con cui il test parla al browser. E arriva a una suite che gira in CI, mocka la rete, si correla alle trace del backend e resta leggibile quando cresce.
Le suite E2E non muoiono di lentezza, muoiono di sfiducia
Test che passano al terzo tentativo. sleep(5000) sparsi nel codice. Suite che girano venti minuti e falliscono in modo non deterministico, sempre su un test diverso. La spiegazione che si sente di solito è che i test end-to-end sono fragili per natura, e che ci si convive.
Non è vero. Quella fragilita' non è una proprietà del testing end-to-end: è una conseguenza di come il test parla al browser. Cambiato quel canale, la maggior parte dei sintomi sparisce senza toccare una riga di logica di test.
Il momento in cui una suite viene abbandonata non è quando diventa lenta: è quando il team smette di credere ai suoi fallimenti. Da li' in avanti continua a costare tempo di CI senza produrre informazione, e chi rilascia impara a premere skip.
Questa serie segue il percorso completo: dal protocollo che genera la flakiness fino a una suite che gira in CI parallelizzata, mocka la rete, si correla alle trace del backend e resta leggibile quando i test diventano centinaia.
Cosa imparerai
- ✓ Capire perché l'auto-waiting elimina i timing bug e cosa non elimina
- ✓ Correlare un test fallito con la trace del backend che lo ha fatto fallire
- ✓ Parallelizzare in CI con lo sharding, e sapere quando il collo di bottiglia si sposta altrove
- ✓ Mockare la rete: da un singolo endpoint al replay di sessioni HAR
- ✓ Diagnosticare un test flaky invece di aggiungere un retry
- ✓ Organizzare la suite con il Page Object Model prima che diventi ingestibile
Articoli della serie
- 01I test E2E non sono fragili. Il protocollo lo era. 7 min
La flakiness dei test E2E non è mancanza di disciplina: è il protocollo con cui il test parla al browser. Auto-waiting, WebSocket, parallelizzazione.
→ - 02Dal test E2E al debug del backend: Playwright + OpenTelemetry 13 min
Come correlare test E2E Playwright con trace OpenTelemetry per identificare il microservizio colpevole quando un test fallisce
→ - 03Playwright in CI/CD: Sharding, Mobile Testing e Automazione Agent-Driven 10 min
Playwright in CI: sharding con blob reporter e job di merge, 200 test su 4 shard in un quarto del tempo, più emulazione mobile e API testing.
→ - 04Playwright: Network Mocking e API Interception per Test Affidabili 12 min
page.route() intercetta le richieste a livello di browser: fulfill, continue e abort. Cinque pattern per mockare API, errori HTTP e stati di caricamento.
→ - 05Playwright: Mock Fixture, HAR Replay e Composizione per Test Scalabili 13 min
Fixture MockApi, HAR replay e composizione: inline per un test solo, fixture dai tre in su, HAR per i flussi con troppe API da mockare a mano.
→ - 06Playwright: Visual Regression Testing per Catturare Bug Invisibili 13 min
Come usare toHaveScreenshot() per catturare bug visivi che i test funzionali non vedono: masking, stati mockati, cross-browser e CI
→ - 07Playwright: Diagnosticare e Risolvere Test Flaky 15 min
Come identificare le cause dei test flaky e risolverle: trace viewer, retry strategico, pattern anti-flaky e checklist diagnostica
→ - 08Playwright: Authentication Testing con storageState e Keycloak 13 min
Come gestire l'autenticazione nei test E2E: storageState per evitare login ripetuti, ruoli multipli, session management e composizione con mock
→ - 09Playwright: Page Object Model per Test Manutenibili 14 min
Come organizzare i test E2E con il Page Object Model: classi riusabili, fixture Playwright, composizione con mock e refactoring guidato
→