La build diventa rossa, qualcuno fa clic su “riesegui”, passa e tutti vanno avanti. Sembra innocuo, ma i test instabili distruggono lentamente la cosa più preziosa che una suite di test possiede: la fiducia delle persone in essa. Quando i fallimenti sono solitamente rumore, vengono segnalati anche bug reali.

Questa guida illustra il motivo per cui i test diventano instabili e come risolvere correttamente ciascuna causa. Abbiamo eseguito le demo di timing e stato condiviso in Python 3.13 e i numeri mostrati provengono da quelle esecuzioni. Si tratta di piccole dimostrazioni progettate per rendere facile vedere la fragilità, quindi i tassi di fallimento saranno diversi.

Cos’è un test traballante?

Un test instabile fornisce risultati diversi sullo stesso codice. Passa in un’esecuzione e fallisce in quella successiva, anche se non è cambiato nulla nel prodotto. Il test potrebbe essere difettoso oppure il codice potrebbe contenere un vero bug intermittente. Questa seconda possibilità è esattamente il motivo per cui non dovresti semplicemente ignorarli.

Perché i test instabili sono così costosi

• Perdita di fiducia. Una volta che le persone presumono che il rosso significhi “probabilmente traballante”, smettono di indagare sui veri fallimenti.
• Tempo sprecato. Gli sviluppatori trascorrono ore a rieseguire pipeline ed esaminare errori che non hanno nulla a che fare con la modifica.
• Consegna più lenta. Le unioni e i rilasci attendono le repliche, minando il punto di CI/CD.
• Bug nascosti. Le condizioni di gara nel prodotto possono assomigliare al rumore del test e sono quelle che danneggiano la produzione.

Le cause più comuni in breve

Causa 1: tempistica e sonni fissi

Questa è la causa più comune. Un test presuppone che il lavoro in background verrà completato dopo un ritardo fisso. Per vedere l’effetto, abbiamo scritto un piccolo test in cui il lavoro dura fino a 2 ms, mentre il test attende solo 1 ms prima di verificare:

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

La soluzione è attendere le condizioni effettive, con un limite superiore generoso:

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

Abbiamo eseguito ciascuna versione 200 volte:

Il risultato è molto più che semplice affidabilità. La versione fissa si sposta nel momento in cui il lavoro viene terminato, quindi di solito è anche più veloce. Una sospensione più lunga farebbe sì che la prima versione fallisca meno spesso, ma ogni esecuzione sarebbe quindi più lenta e potrebbe comunque fallire su una macchina CI occupata.

Nei test del browser si applica lo stesso principio. Utilizza l’attesa automatica di Drammaturgo, o le Attese di selenio esplicite, invece di time.sleep:

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

Causa 2: stato condiviso e ordine di test

Quando i test condividono dati, uno può influenzarne un altro e il risultato dipende dall’ordine in cui vengono eseguiti. Questi due test utilizzano un elenco condiviso:

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

La nostra esecuzione lo ha confermato, ed è per questo che una suite può durare mesi e poi rompersi quando qualcuno aggiunge esecuzioni parallele o un plug-in per l’ordine casuale. La cura è l’isolamento:

• Fornisci a ogni test dati aggiornati, utilizzando un dispositivo che lo imposta e lo pulisce. Il nostro tutorial pytest mostra come.
• Crea record univoci, come un’e-mail con un suffisso casuale, al posto di un “utente di prova” condiviso.
• Avvolgi i test del database in una transazione ed esegui il rollback, laddove la tua configurazione lo consente.
• Esegui regolarmente i test in ordine casuale, in modo che questi problemi si manifestino presto.

Causa 3: date, fusi orari e casualità

Un test che supera tutta la settimana può fallire il sabato, a mezzanotte o l’ultimo giorno del mese. Rendi il tempo un input, invece di leggere l’orologio all’interno della tua logica:

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

Questi test danno la stessa risposta ogni giorno. Allo stesso modo, imposta un seed fisso per valori casuali nei test e registralo quando utilizzi dati casuali in modo da poter riprodurre un errore. Non assumere un ordine particolare da insiemi, dizionari da fonti esterne o query di database senza ORDER BY.

Causa 4: Selettori fragili

Un test che trova un pulsante con div:nth-child(3) > span si interrompe con qualsiasi modifica al layout e potrebbe fallire solo per alcune dimensioni o varianti dello schermo. Preferire i localizzatori in base a ciò che vedono gli utenti o attributi di test dedicati. La nostra guida ai Locatori di drammaturghi spiega l’ordine in cui provarli. Le animazioni sono un’altra frequente fonte di problemi, quindi considera la possibilità di disabilitarle negli ambienti di test.

Causa 5: servizi e reti esterni

Se un test chiama un vero fornitore di servizi di pagamento o un’API di terze parti, il risultato dipende dai tempi di attività e dai limiti di velocità di qualcun altro. Prendi in giro quelle chiamate per la maggior parte dei test e mantieni un piccolo numero di controlli contrattuali separati rispetto al servizio reale, in modo da sapere comunque se cambia. La nostra guida ai test unitari e di integrazione spiega come suddividerli.

Come diagnosticare un test traballante

1. Confermalo. Esegui il test più volte senza apportare modifiche. Con pytest, funziona un semplice ciclo di shell e un plugin come pytest-repeat ti dà --count=100.
2. Registra prove. Salva registri, screenshot e tracce per ogni errore. Il visualizzatore di tracce di Playwright è particolarmente utile qui.
3. Sottolinea le condizioni. Eseguilo con CPU limitata, in parallelo o in ordine casuale. Far fallire più spesso rende più facile studiare.
4. Testalo da solo. Se passa sempre da solo ma fallisce nella suite, sospetta lo stato condiviso.
5. Cerca modelli. Controlla quali macchine, orari del giorno e test vicini sono coinvolti.
6. Controlla il prodotto. Chiedi onestamente se questa potrebbe essere una vera e propria condizione di gara nella tua applicazione.

I tentativi automatici sono una soluzione?

I nuovi tentativi sono un’utile rete di sicurezza a breve termine e non sono una cura. Un singolo tentativo automatico in CI può continuare a lavorare mentre indaghi, ma un test che necessita di un nuovo tentativo per essere superato ti dice comunque qualcosa. Peggio ancora, un vero bug intermittente del prodotto che fallisce il 20% delle volte di solito passa inosservato dopo un nuovo tentativo.

Usa i tentativi con queste regole: limitali a uno o due, registra ogni test che ne richiedeva uno e tratta quell’elenco come la tua lista di cose da fare. Un test segnalato come “superato al nuovo tentativo” dovrebbe essere considerato un problema su cui indagare, non un successo.

Un processo di squadra per test instabili

1. Misura. Tieni traccia dei test falliti e poi passa lo stesso commit. Molti strumenti CI e reporter di test possono dimostrarlo.
2. Quarantena. Sposta un test instabile confermato fuori dall’esecuzione del blocco, in modo che smetta di disturbare tutti, ma continua a eseguirlo e a monitorarlo.
3. Assegna un proprietario e una scadenza. Una quarantena senza scadenza diventa semplicemente un cimitero.
4. Correggi o elimina. Se non vale la pena correggere un test, rimuovilo e controlla che la sua copertura esista ancora altrove.
5. Prevenire. Esegui nuovi test più volte prima di unirli. Un test che fallisce una volta su cinquanta viene eseguito meglio adesso che tra sei mesi.

Tratta un test instabile come un bug con priorità e non come rumore di fondo. Anche qui si applicano gravità e priorità, come spiegato in gravità e priorità. Se l’instabilità è diffusa, leggi gli errori di automazione dei test più ampi e valuta se hai troppi test a livello di browser.

Considerazioni finali

I test instabili sembrano casuali, ma raramente lo sono. Quasi tutti si basano su un presupposto sul tempo, sull’ordine, sui dati o sull’ambiente che non è sempre vero. Scegli il test che fallisce più spesso nella tua pipeline questa settimana. Eseguilo cinquanta volte, trova il presupposto e risolvilo per sempre. Una vera soluzione insegna a una squadra che più di un centinaio di repliche potranno mai farlo.

Domande frequenti

Continua a imparare