Risposta.

Il meccanismo di retry dei test viene implementato per aumentare la stabilità del pipeline di test e combattere i test flaky, ma richiede un approccio sensato.

Storia della questione È emerso come workaround per errori infrastrutturali temporanei o flaky non correlati agli errori dell'applicazione (ambiente instabile, problemi di rete, timeout casuali delle API). Molti sistemi CI/CD ora supportano il retry integrato.

Problema Un retry eccessivo o incontrollato può nascondere bug reali o trasformare i fallimenti in "semplici fenomeni temporanei". Si verificano risultati falsi positivi: il test sembra essere riuscito, ma il bug è comunque presente.

Soluzione Attivare il retry solo per test instabili o dipendenti da risorse esterne, utilizzare tag o marcatori. Limite fisso di ripetizioni (1-2 volte). Registrare tutti i fallimenti e i successi delle esecuzioni ripetute per analizzare le cause dei guasti.

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # Test che può fallire a causa dell'instabilità dell'API
    ...

Caratteristiche chiave:

Applicare in modo mirato e consapevole
Analizzare sempre le cause dei retry
Non mascherare i bug dell'app, ma solo quelli infrastrutturali/flaky

Domande insidiose.

È possibile eseguire il retry di tutti gli autotest nel pipeline?

Questa è una cattiva pratica: si nascondono sia i bug reali che i problemi architettonici dei test. Il retry è un caso estremo per alcuni tipi di test.

Cosa fare se dopo 3 retry il test non passa ancora?

Interrompere l'esecuzione e aprire un bug per instabilità/inchiesta: così si identificano errori complicati che richiedono refactoring.

Se un test passa al secondo tentativo, significa che va tutto bene?

No, l'unico stato corretto è il passaggio stabile al primo tentativo. Pasaggio al secondo è un indicatore di problemi (flaky o infrastrutturali).

Errori tipici e anti-pattern

Applicazione incontrollata del retry che nasconde bug
Mancanza di analisi delle cause dei fallimenti
Utilizzo del retry invece di risolvere i problemi reali

Esempio della vita reale

Caso negativo

Per tutto il pipeline di Jenkins è stato attivato un retry globale di due esecuzioni. Dopo un mese, i bug a causa di race condition nel codice si sono diffusi, e il team pensava che "la qualità fosse ok". Il prodotto è improvvisamente crollato in produzione a causa degli stessi bug.

Pro:

Ci sono stati pipeline verdi

Contro:

I bug dell'app non sono stati identificati in tempo
Durante le indagini è difficile capire la fonte dell'affidabilità

Caso positivo

Per la categoria di test con API esterne è stato impostato il retry solo su di esse (per tag). Tutti gli altri test passano rigorosamente al primo tentativo. Attraverso i log, il team indaga e registra i fallimenti ripetitivi.