Risposta.

L'automazione dei test è storicamente iniziata con l'idea di aumentare la velocità e ridurre il fattore umano nei controlli, ma è presto emerso che i test automatici spesso si comportano in modo diverso ad ogni esecuzione. La ripetibilità (repeatability) e la determinazione sono alcuni dei requisiti fondamentali per la qualità dei test automatici, che devono fornire lo stesso risultato in condizioni identiche.

I problemi iniziano a causa di dipendenze implicite: dati di test instabili, ambienti non sincronizzati, processi paralleli o servizi esterni. Questo porta a test flaky, i cui risultati non possono essere previsti.

Le soluzioni si concentrano sul controllo rigoroso dell'ambiente di esecuzione, sull'isolamento dei test, sull'uso di oggetti mock/stub, dati statici e scenari riproducibili (ad esempio, pulizia e preparazione del database prima di ogni test).

Caratteristiche chiave:

Controllo dei dati di test e inizializzazione prevedibile dell'ambiente di test.
Isolamento dei test l'uno dall'altro e rinuncia alle dipendenze tra test.
Utilizzo di oggetti Mock/Stub per lavorare con servizi instabili o esterni.

Domande trabocchetto.

Cosa fare se il test flaky si verifica solo in CI, mentre localmente è tutto stabile?

Questo è quasi sempre dovuto a differenze negli ambienti: versioni delle dipendenze, velocità di funzionamento dell'infrastruttura, parallelismo, impostazioni del sistema operativo o ordine di esecuzione dei test. La soluzione è avvicinare il più possibile l'ambiente CI alla macchina di sviluppo (Docker, valori seed identici, configurazione setUp/tearDown nei test).

Si possono considerare i test parametrizzati completamente deterministici se i dati provengono da un database?

No. Anche se i dati coincidono a livello di base, il database può cambiare tra i test o tra le release. Per una vera determinazione, i dati devono essere preparati e puliti esplicitamente in ogni test.

Se utilizzo sleep per aspettare il caricamento degli elementi, risolverà questo problema di instabilità dei test UI?

No. Sleep maschera solo il problema e rallenta l'esecuzione dei test. È corretto utilizzare attese esplicite (Explicit Waits) che attendono specifiche condizioni e non un tempo fisso.

Errori tipici e anti-pattern

Uso di "numeri magici" e ritardi invece di una corretta sincronizzazione.
Dipendenza tra test o modifica dello stato dell'ambiente che non viene ripristinato tra i test.
Mescolanza di dati di test tra scenari.

Esempio dalla vita reale

Caso negativo

In un progetto, sono stati eseguiti test UI su un ambiente che nessuno ha pulito dopo i test manuali. Una volta ogni tanto, i test fallivano con errori "randomici", che non si verificavano localmente. Il team ha aggiunto sleep nei test e ha ignorato i problemi flaky.

Pro:

Non è stato necessario investire molto tempo per risolvere il problema alla radice.
I test a volte comunque consentivano di trovare bug.

Contro:

Tempo sprecato per ripetuti tentativi.
Risultati falsamente negativi demotivavano gli ingegneri.
I rapporti erano coperti da rumore; la vera regressione potrebbe essere stata trascurata.

Caso positivo

Dopo l'arrivo di un ingegnere DevOps esperto, il team ha implementato script per azzerare e inizializzare i dati di test, ha aggiunto mock service per integrazioni instabili e ha iniziato a eseguire i test in contenitori. I test flaky sono praticamente scomparsi.