Episodio 2: di Vasilii a Monaco (maggio 2019)
Puntate precedenti
I test irregolari sono un problema comune in Chrome. Influiscono sulla produttività di altri sviluppatori e vengono disattivati nel tempo. I test disattivati riducono la copertura dei test.
Fase di classificazione
I PROPRIETARI delle directory sono responsabili della correzione dei test instabili. Se hai ricevuto un bug relativo a un test instabile, dedica qualche minuto a commentare il problema. Se hai un test instabile precedente e non ti è chiaro cosa non ha funzionato, prova semplicemente a riattivarlo. Riassegna il bug il prima possibile se si tratta chiaramente di un problema in un altro componente. I proprietari del componente dovrebbero avere un giudizio migliore sull'errore,
Fase di debug
Alcuni flag della riga di comando sono utili per correggere i test instabili. Ad esempio, --enable-pixel-output-in-tests
mostrerà l'effettiva UI del browser.
Avere strumenti di riserva se il debugger fa scomparire le irregolarità. È possibile che, nel debugger, il test non sia mai irregolare. In questo caso, possono essere utili le istruzioni di log o base::debug::StackTrace.
Tieni presente i motivi comuni degli errori di EXPECT__* oltre ai bug nel codice di produzione:
- Aspettative errate (ad es. pagina protetta significa HTTPS; può invece essere un localhost).
- Condizioni di gara a causa di test non in attesa dell'evento corretto.
[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 cambiare in tre in futuro, rendendo il test irregolare. Tuttavia, solo lo stato del negozio è pertinente. Utilizza invece un osservatore per il negozio.
Fai attenzione a schemi comuni come i seguenti:
Submit TestPasswordForm(); // Wait until things settle down. RunLoop().RunUntilIdle(); CheckCredentialPromptVisible();
Uno snippet come quello sopra, tratto da un test del browser, è quasi certamente errato. Prima che venga visualizzata una UI, potrebbero verificarsi molti eventi in processi e thread diversi.
Di seguito è riportata una correzione corretta:
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
La correzione riportata sopra è corretta partendo dal presupposto che WaitUntilCredentialPromptVisible() non controlla effettivamente l'interfaccia utente.
I test del browser non devono dipendere da eventi dell'interfaccia utente esterni come "focus perso" o "finestra diventa in primo piano". Immagina un'implementazione in cui il prompt
viene visualizzato solo quando la finestra del browser è attiva. Un'implementazione di questo tipo
sarebbe corretta; tuttavia, controllare la finestra effettiva rende il test irregolare.
Fase post-correzione
Una volta risolto il test, eseguilo centinaia di volte localmente. Tieni d'occhio il portale Flakiness.