Aflevering 2: door Vasilii in München (mei 2019)
Vorige afleveringen
Slechte tests zijn een veelvoorkomend probleem in Chrome. Ze hebben invloed op de productiviteit van andere ontwikkelaars en worden na verloop van tijd uitgeschakeld. Uitgeschakelde tests betekenen een afnemende testdekking.
Triage-fase
De EIGENAARS van mappen zijn verantwoordelijk voor het repareren van hun slechte tests. Als je een bug hebt ontvangen over een slechte test, neem dan een paar minuten de tijd en becommentarieer wat er mis is gegaan met de bug. Als je een oude, slechte test hebt en het onduidelijk is wat er mis is gegaan, probeer dan de test eenvoudigweg opnieuw in te schakelen . Wijs de bug zo snel mogelijk opnieuw toe als het duidelijk een probleem is in een ander onderdeel. De eigenaren van dat onderdeel zouden een beter oordeel moeten hebben over de storing,
Fase van foutopsporing
Een aantal opdrachtregelvlaggen zijn handig voor het oplossen van slechte tests. --enable-pixel-output-in-tests zal bijvoorbeeld de daadwerkelijke gebruikersinterface van de browser weergeven.
Zorg voor terugvaltools als de debugger schilfers laat verdwijnen. Het is mogelijk dat de test onder debugger nooit onbetrouwbaar is. In dat geval kunnen log-instructies of base::debug::StackTrace handig zijn.
Houd rekening met veelvoorkomende redenen voor EXPECT__* fouten, naast bugs in productiecode:
- Onjuiste verwachtingen (beveiligde pagina betekent bijvoorbeeld HTTPS; het kan in plaats daarvan een localhost zijn).
- Raceomstandigheden als gevolg van tests die niet wachten op het juiste evenement.
[Test niet de implementatie][niet-implementatie] maar het gedrag.
// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();
Mogelijk veranderen de twee retourvluchten in de toekomst in drie, waardoor de proef wankel wordt. Alleen de winkelstatus is echter relevant. Gebruik in plaats daarvan een waarnemer voor de winkel.
Pas op voor veelvoorkomende patronen, zoals de volgende:
Submit TestPasswordForm(); // Wait until things settle down. RunLoop().RunUntilIdle(); CheckCredentialPromptVisible();
Een fragment zoals hierboven uit een browsertest is vrijwel zeker onjuist. Er zijn veel gebeurtenissen die in verschillende processen en threads moeten plaatsvinden voordat er een gebruikersinterface verschijnt.
Het volgende is een correcte oplossing:
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
De bovenstaande oplossing is correct in de veronderstelling dat WaitUntilCredentialPromptVisible() de gebruikersinterface niet daadwerkelijk controleert. De browsertests mogen niet afhankelijk zijn van externe UI-gebeurtenissen zoals "focus verloren" of "venster werd voorgrond". Stel je een implementatie voor waarbij de prompt alleen verschijnt als het browservenster actief is. Een dergelijke implementatie zou correct zijn; het controleren op het daadwerkelijke venster maakt de test echter wankel.
Fase na reparatie
Zodra de test is opgelost, voert u deze honderden keren lokaal uit. Houd het Flakiness-portaal in de gaten.