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

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

Częstym problemem w Chrome są niepewne testy. Wpływają one na produktywność innych programistów i z czasem zostają wyłączone. Wyłączone testy oznaczają zmniejszenie zasięgu testów.

Etap klasyfikacji

WŁAŚCICIELE katalogów są odpowiedzialne za naprawienie niepewnych testów. Jeśli otrzymasz komunikat o błędzie dotyczącym niepewnego testu, poświęć kilka minut i napisz, co poszło nie tak. Jeśli masz stary, niepewny test i nie wiesz, co poszło nie tak, spróbuj go po prostu ponownie włączyć. Jak najszybciej ponownie przypisz błąd, jeśli stanowi on wyraźnie problem w innym komponencie. Właściciele tego komponentu powinni lepiej ocenić, czy coś się nie udało,

Etap debugowania

Do rozwiązywania niestabilnych testów przydaje się szereg flag wiersza poleceń. Na przykład --enable-pixel-output-in-tests wyrenderuje rzeczywisty interfejs przeglądarki.

Mają narzędzia zastępcze, jeśli debuger sprawia, że niestabilność znika. Może się zdarzyć, że w trakcie korzystania z debugera test nie będzie niestabilny. W takim przypadku przydatne mogą być instrukcje logów lub base::debug::StackTrace.

Nie

Pamiętaj, że oprócz błędów w kodzie produkcyjnym typowe przyczyny błędów w EXPECT__*:

  • Niewłaściwe oczekiwania (np. bezpieczna strona oznacza protokół HTTPS, a zamiast tego może to być host lokalny).
  • Warunki wyścigu spowodowane przez testy nieoczekiwania na odpowiednie wydarzenie.

[Nie testuj implementacji][nie-implementacja], ale jej zachowanie.

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

Dwie wymiany w obie strony mogą w przyszłości zmienić się w 3, przez co test będzie niepewny. Uwzględniany jest jednak tylko stan sklepu. Zamiast tego użyj obserwatora sklepu.

Nie

Uważaj na typowe wzorce, np.:

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

Fragmenty takie jak powyższy fragment z testu przeglądarki są niemal na pewno nieprawidłowe. Jest wiele zdarzeń, które powinny wystąpić w różnych procesach i wątkach, zanim pojawi się interfejs.

Tak

Oto poprawka:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

Powyższa poprawka jest poprawna przy założeniu, że WaitUntilCredentialPromptVisible() w rzeczywistości nie sprawdza interfejsu użytkownika. Testy przeglądarki nie powinny zależeć od zewnętrznych zdarzeń interfejsu, takich jak „utracono zaznaczenie” lub „okno stało się na pierwszym planie”. Wyobraź sobie implementację, w której pytanie pojawia się tylko wtedy, gdy okno przeglądarki jest aktywne. Taka implementacja jest prawidłowa, ale sprawdzanie rzeczywistego okna powoduje niestabilne wyniki testu.

Etap naprawy

Po rozwiązaniu testu uruchom go setki razy lokalnie. Regularnie odwiedzaj portal Flakiness.