Flaky test (test instabile)

Un flaky test (test instabile) dà un risultato diverso sullo stesso commit. Eseguilo dieci volte sul codice invariato e otterrai alcuni successi e alcuni fallimenti. La caratteristica che lo definisce è che nel prodotto non è cambiato nulla: la variazione nasce dal test, dai suoi dati o dal suo ambiente.

Perché è importante

Una suite con qualche flaky test insegna al team a rieseguire i fallimenti finché non diventano verdi. Una volta presa questa abitudine, anche le regressioni reali vengono “rieseguite via”. L’instabilità rallenta anche le pipeline, perché i retry moltiplicano il tempo di esecuzione, ed erode la fiducia nell’automazione più in fretta di quanto faccia una copertura mancante.

Cause comuni

• Tempistiche. Il test agisce prima che la pagina o l’API siano pronte: un sleep fisso, un controllo che legge un valore una sola volta invece di riprovare, o un’animazione ancora in corso.
• Stato condiviso. Due test scrivono lo stesso utente, lo stesso carrello o la stessa riga del database. Passano da soli e falliscono in parallelo o in un ordine diverso.
• Dipendenza dall’ordine dei test. Un test si basa su dati creati da un test precedente.
• Ambiente. Ambienti di test lenti o condivisi, servizi di terze parti, rate limit, fusi orari e cambi d’ora.
• Dati non deterministici. Input casuali senza un seed registrato, o asserzioni su “adesso”.

Come affrontarne uno

1. Riproducilo. Esegui il singolo test in un ciclo (Playwright: npx playwright test my.spec.ts --repeat-each=20) e cattura una trace o un video di un’esecuzione fallita.
2. Trova la causa invece di aggiungere un retry. Sostituisci le pause con attese basate su condizioni, come le asserzioni web-first in Playwright o WebDriverWait in Selenium. Dai a ogni test i propri dati.
3. Mettilo in quarantena se non riesci a correggerlo oggi. Spostalo fuori dal gate bloccante in un job tracciato e non bloccante, con un responsabile, così che il segnale principale resti affidabile.
4. Monitora nel tempo il tasso di instabilità. I retry che passano nascondono il problema, a meno che il report non li mostri.

I retry (retries: 2 in playwright.config.ts) sono una rete di sicurezza ragionevole in CI, ma un test che passa solo al retry resta comunque instabile. Playwright li segnala come “flaky”, così puoi vederli.