Risposta.

I flaky test sono test che possono passare o fallire senza modifiche nel codice, a causa di fattori esterni casuali. Minano la fiducia nell'automazione e complicano i processi CI/CD.

Storia della questione: La tensione con i flaky test è emersa con l'arrivo di test E2E, test di integrazione e test UI in massa, quando la stabilità dell'ambiente e dei servizi dipendenti non è garantita. Inizialmente, tali fallimenti venivano ignorati o "riavviati manualmente".

Problema:

I flaky test rendono l'esecuzione automatica dei test inaffidabile.
Gli sviluppatori iniziano a perdere veri fallimenti, credendoli falsi.
Aumenta il tempo di manutenzione dei test e si richiede un'analisi manuale dei risultati instabili.

Soluzione:

Gestione separata dei flaky test. Etichettare (ad esempio, @FlakyTest) o collocarli in una categoria separata.
Ri-esecuzione automatica. In caso di fallimento del test, ripetere X volte — se fallisce non sempre, il test viene contrassegnato come instabile.
Analisi delle cause di instabilità: utilizzo di log, snapshot di stato, monitoraggio delle risorse (ad esempio, rete instabile, code o funzionamento errato del GC).
Correzione graduale: lavorare sull'ambiente di test, semplificare gli scenari, fare mocking delle dipendenze instabili.

Esempio di codice per auto-retry:

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # codice del test

Caratteristiche chiave:

È importante separare i flaky test dai veri fallimenti
Non si deve semplicemente "ri-eseguire tutto" — i veri bug non devono essere trascurati
Il stato del test deve essere regolarmente analizzato e documentato, e non taciuto

Domande insidiose.

I flaky test sono sempre un problema di infrastruttura?

No, i flaky possono essere causati da errori nella logica di business, race conditions nel codice, asincronia o gestione errata del tempo.

È sufficiente riavviare semplicemente i test falliti?

No, i retry mascherano solo il problema. È necessario cercare e risolvere la causa.

È opportuno eliminare tutti i test instabili?

No, devono essere isolati temporaneamente e le cause devono essere corrette, non semplicemente escluse per sempre.

Errori comuni e anti-pattern

Ignorare i flaky, il che porta a non rilevare seri bug.
Retry di massa senza analizzare le cause.
Contrassegnare test importanti come flaky senza prendere misure per risolverli.

Esempio pratico

Caso negativo

Nel progetto, i flaky test venivano semplicemente contrassegnati e non toccati più, considerandoli un problema "irrisolvibile".

Vantaggi:

Riduzione del numero di "rosse" false build

Svantaggi:

I veri bug arrivano in produzione
Verifica manuale costante dei risultati

Caso positivo

Per ogni test instabile è stata introdotta una ripetizione automatica e una gestione interna dell'instabilità. Sono state effettuate revisioni regolari congiunte delle cause e corrette i bug man mano che si accumulavano.