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
.
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.
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.
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.