Chromium Chronicle #2: walka z problemami z pojawianiem się testu

Odcinek 2: Vasilii w Monachium (maj 2019 r.)
Poprzednie odcinki

Testy niepewne to częsty problem w Chrome. Ta wpływają na produktywność innych programistów i z czasem zostaną wyłączone. Wyłączenie testów oznacza zmniejszenie zasięgu testów.

Etap klasyfikacji

WŁAŚCICIELE katalogów są odpowiedzialni za naprawianie niestabilnych testów. Jeśli otrzymasz komunikat o błędzie dotyczącym niepewnego testu, poświęć kilka minut dodać komentarz, co poszło nie tak. Jeśli masz stary test z niepewnymi wynikami nie masz pewności, co poszło nie tak. Po prostu ponownie włącz test. Jak najszybciej przypisz błąd ponownie, jeśli stanowi on problem w innym komponencie. Właściciele tego komponentu powinni mieć większą wiedzę na temat awarii,

Etap debugowania

Szereg flag wiersza poleceń przydaje się i poprawiać niestabilne testy. Na przykład: --enable-pixel-output-in-tests. spowoduje wyrenderowanie rzeczywistego interfejsu przeglądarki.

Jeśli debuger powoduje usunięcie niestabilności, skorzystaj z narzędzi zastępczych. Jest może się zdarzyć, że podczas korzystania z debugera test nigdy nie będzie niestabilny. W takim przypadku zapisz lub base::debug::StackTrace mogą okazać się przydatne.

Nie

Pamiętaj o typowych przyczynach błędów w EXPECT__* oprócz błędów w wersji produkcyjnej kod:

  • nieprawidłowych oczekiwań (np. zabezpieczona strona oznacza HTTPS; może to być host lokalny);
  • Warunki wyścigu wynikające z testów, które nie oczekują na odpowiednie zdarzenie.

[Nie testuj implementacji][not-implementation], ale ich działania.

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

W przyszłości te 2 podróże w obie strony mogą się zmienić na 3, przez co test będzie niepewny. Znaczenie ma jednak tylko stan sklepu. Zamiast tego użyj obserwatora, sklepu.

Nie

Zwracaj uwagę na typowe wzorce, takie jak:

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

Fragment podobny do powyższego z testu przeglądarki prawie na pewno jest nieprawidłowy. Jest wiele zdarzeń, które powinny mieć miejsce w różnych procesach zanim pojawi się jakiś interfejs.

Tak

Oto poprawna poprawka:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

Powyższa poprawka jest poprawna przy założeniu, że WaitUntilCredentialPromptVisible() nie sprawdza interfejsu. Testy przeglądarki nie powinny zależeć od zewnętrznych zdarzeń interfejsu takich jak „utracone skupienie” lub „Okno stał się pierwszym planem”. Wyobraź sobie, że prośba o podanie jest wyświetlana tylko wtedy, gdy okno przeglądarki jest aktywne. Taka implementacja byłby prawidłowy. jednak sprawdzenie rzeczywistego okna powoduje niestabilne wyniki testu.

Etap po naprawie

Po naprawieniu testu uruchom go setki razy lokalnie. Sprawdzaj Portal niepewności.