Flaky Tests — Cheat Sheet

Tag: testing, qa, ci-cd, automation, flaky

Livello: intermedio

TL;DR: I flaky test sono test che falliscono o passano in modo intermittente senza modifiche al codice. Riducono la fiducia nella CI/CD e richiedono strategie di isolamento e retry.

Concetti chiave

• Un test è "flaky" se il suo esito (pass/fail) non è deterministico a parità di codice.
• Cause comuni: dipendenze esterne (API, database), condizioni di race, asincronia mal gestita, ordine di esecuzione dipendente, pulizia dello stato incompleta.
• Impatto: minano la fiducia della pipeline; gli sviluppatori tendono a ignorare i fallimenti veri pensando siano "solo un altro flaky test".
• Costi: tempo perso in re-run, debug complesso, colli di bottiglia nelle release.
• Risoluzione: isolamento del test, mock affidabili, attese esplicite (wait) invece di sleep arbitrari, test idempotenti.

Domande tipiche e risposte pronte

• Q: Cos'è un flaky test e perché è pericoloso?

R: È un test che passa o fallisce casualmente senza che il codice cambi. È pericoloso perché fa perdere fiducia nella test suite: se un test fallisce, non so più se è un vero bug o un falso positivo.

• Q: Come affronti i flaky test nel tuo progetto?

R: Li isolo mettendoli in quarantena o skippandoli (con ticket di fix). Poi analizzo log e retry, verificando se dipendono da asincronia (aggiungo wait espliciti), state leakage (miglioro setup/teardown) o dipendenze esterne (uso mock).

• Q: Quando è accettabile usare i retry automatici nella CI?

R: Come soluzione temporanea per test e2e o di integrazione molto complessi (es. UI testing), ma non deve mascherare il problema alla radice. I test unitari non dovrebbero mai avere retry.

Insidie e errori comuni

• Usare sleep() o timeout fissi per gestire l'asincronia, invece di wait espliciti o polling intelligente.
• Condividere lo stato tra i test senza un corretto blocco di pulizia (teardown), creando dipendenza dall'ordine di esecuzione.
• Affidarsi a dati dinamici (es. date correnti) non mockati, che fanno fallire il test al cambio giorno/ora.
• Ignorarli per lungo tempo, accumulando un "debito di test" che paralizza la CI.

Da ripassare

• [ ] Pattern Retry Loop per test E2E.
• [ ] Tecniche di mocking per isolare le dipendenze esterne.
• [ ] Strategie di quarantena dei test.

```