The Chromium Chronicle n. 2: Fighting Test Flakiness

Episodio 2: di Vasilii a Monaco (maggio 2019)
Puntate precedenti

I test irregolari sono un problema comune in Chrome. Loro influiranno sulla produttività di altri sviluppatori e verranno disattivate nel tempo. Se i test vengono disattivati, la copertura dei test sarà ridotta.

Fase di valutazione

I PROPRIETARI delle directory sono responsabili della correzione dei loro test irregolari. Se hai ricevuto un bug relativo a un test instabile, dedica qualche minuto alla commenta cosa non ha funzionato sul bug. Se hai un vecchio test instabile e cosa non è chiaro, prova semplicemente a riattivare il test. Riassegna il bug appena possibile se è chiaramente un problema in un altro componente. I proprietari di quel componente dovrebbero avere un migliore giudizio sull'errore

Fase di debug

Una serie di flag della riga di comando è utile per risolvere test irregolari. Ad esempio, --enable-pixel-output-in-tests per visualizzare l'effettiva UI del browser.

Disporre di strumenti di riserva se il debugger scompare. È è possibile che, nel debugger, il test non sia mai irregolare. In tal caso, registra o base::debug::StackTrace possono essere utili.

Cosa non fare

Tieni presente i motivi comuni degli errori di EXPECT__* oltre ai bug in produzione codice:

  • Aspettative errate (ad esempio, pagina sicura significa HTTPS; può invece essere un localhost).
  • Condizioni della gara dovute a test non in attesa dell'evento giusto.

[Non testare l'implementazione][non l'implementazione], ma il comportamento.

// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();

I due viaggi di andata e ritorno potrebbero diventare tre in futuro, rendendo il test instabile. Tuttavia, solo lo stato del negozio è pertinente. Usa invece un osservatore per .

Cosa non fare

Presta attenzione agli schemi comuni, come i seguenti:

Submit TestPasswordForm();
// Wait until things settle down.
RunLoop().RunUntilIdle();
CheckCredentialPromptVisible();

Uno snippet come quello mostrato sopra, proveniente da un test del browser, è quasi sicuramente errato. Ci sono molti eventi che dovrebbero verificarsi in diversi processi e thread prima che vengano visualizzate alcune UI.

Cosa fare

Di seguito è riportata una correzione corretta:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

La correzione precedente è corretta partendo dal presupposto che WaitUntilCredentialPromptVisible() non controlla effettivamente la UI. I test del browser non dovrebbero dipendere da eventi UI esterni come "Attenzione persa" o "la finestra è diventata in primo piano". Immagina un'implementazione in cui il prompt appare solo quando la finestra del browser è attiva. Una tale implementazione sarebbe la risposta corretta. Tuttavia, controllare la finestra effettiva rende il test poco affidabile.

Fase post-correzione

Una volta corretto il test, eseguilo centinaia di volte in locale. Tieni d'occhio Portale debolezza.