Kompilacja staje się czerwona, ktoś klika „Uruchom ponownie”, przechodzi i wszyscy idą dalej. Wydaje się to nieszkodliwe, ale niestabilne testy powoli niszczą najcenniejszą rzecz, jaką ma zestaw testów: zaufanie ludzi do niego. Kiedy awarie są zwykle hałasem, pojawiają się także prawdziwe błędy.

W tym przewodniku opisano, dlaczego testy działają nieprawidłowo i jak prawidłowo naprawić każdą przyczynę. W Pythonie 3.13 uruchomiliśmy demonstracje synchronizacji i stanu współdzielonego, a pokazane liczby pochodzą z tych przebiegów. Są to małe demonstracje zaprojektowane tak, aby łatwo było dostrzec łuszczenie się, więc Twoje własne wskaźniki awaryjności będą się różnić.

Co to jest test niestabilny?

Niestabilny test daje różne wyniki w tym samym kodzie. W jednym przebiegu przechodzi pomyślnie, a w kolejnym kończy się niepowodzeniem, mimo że w produkcie nic się nie zmieniło. Test może być wadliwy lub kod może zawierać naprawdę sporadyczny błąd. Ta druga możliwość jest właśnie powodem, dla którego nie powinieneś ich po prostu odrzucać.

Dlaczego niestabilne testy są tak kosztowne

• Utracone zaufanie. Kiedy ludzie założą się, że kolor czerwony oznacza „prawdopodobnie niestabilny”, przestają badać prawdziwe awarie.
• Zmarnowany czas. Programiści spędzają godziny na ponownym uruchamianiu potoków i badaniu błędów, które nie mają nic wspólnego z ich zmianami.
• Wolniejsze dostarczanie. Łączenia i wydania czekają na powtórki, podważając sens CI/CD.
• Ukryte błędy. Warunki wyścigowe w produkcie mogą wyglądać jak hałas testowy i to właśnie one szkodzą w produkcji.

Najczęstsze przyczyny w skrócie

Przyczyna 1: Czas i stałe godziny snu

Jest to najczęstsza przyczyna. Test zakłada, że ​​praca w tle zostanie zakończona po ustalonym opóźnieniu. Aby zobaczyć efekt napisaliśmy mały test, w którym praca trwa do 2 ms, natomiast test czeka tylko 1 ms przed sprawdzeniem:

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

Rozwiązaniem jest poczekanie na rzeczywisty stan, z dużym górnym limitem:

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

Każdą wersję uruchomiliśmy 200 razy:

Rezultatem jest coś więcej niż tylko niezawodność. Wersja naprawiona działa dalej w momencie zakończenia pracy, więc zwykle jest też szybsza. Dłuższy tryb uśpienia sprawi, że pierwsza wersja zawiedzie rzadziej, ale każde uruchomienie będzie wówczas wolniejsze i nadal może zakończyć się niepowodzeniem na obciążonej maszynie CI.

W testach przeglądarki obowiązuje ta sama zasada. Użyj automatycznego oczekiwania Playwright lub jawnego Selenium czeka zamiast time.sleep:

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

Przyczyna 2: Stan udostępniony i kolejność testów

Kiedy testy udostępniają dane, jeden może wpływać na inny, a wynik zależy od kolejności, w jakiej są uruchamiane. Te dwa testy korzystają z jednej wspólnej listy:

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

Nasz test to potwierdził i dlatego pakiet może działać miesiącami, a potem się zepsuć, gdy ktoś doda równoległe uruchomienia lub losową wtyczkę. Lekarstwem jest izolacja:

• Daj każdemu testowi świeże dane, używając urządzenia, które je konfiguruje i czyści. Nasz samouczek dotyczący testów Pythona pokazuje, jak to zrobić.
• Twórz unikalne rekordy, takie jak e-mail z losowym sufiksem, zamiast udostępnionego „użytkownika testowego”.
• Zawiń testy bazy danych w transakcję i wycofaj je, jeśli pozwala na to konfiguracja.
• Regularnie przeprowadzaj testy w losowej kolejności, aby problemy te pojawiały się wcześnie.

Przyczyna 3: Daty, strefy czasowe i losowość

Test, który zaliczony jest przez cały tydzień, może zakończyć się niepowodzeniem w sobotę, o północy lub ostatniego dnia miesiąca. Ustaw czas jako dane wejściowe, zamiast czytać zegar w swojej logice:

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

Testy te dają tę samą odpowiedź każdego dnia. Podobnie, ustaw stałe ziarno dla wartości losowych w testach i zarejestruj je, gdy użyjesz danych losowych, aby móc odtworzyć awarię. Nie zakładaj określonej kolejności ze zbiorów, słowników ze źródeł zewnętrznych lub zapytań do baz danych z numerem ORDER BY.

Przyczyna 4: Kruche selektory

Test, który znajdzie przycisk z div:nth-child(3) > span, kończy się niepowodzeniem przy jakichkolwiek zmianach układu i może zakończyć się niepowodzeniem tylko w przypadku niektórych rozmiarów lub wariantów ekranu. Preferuj lokalizatory oparte na tym, co widzą użytkownicy, lub dedykowane atrybuty testowe. W naszym przewodniku po lokatorach dramaturgów wyjaśniono, w jakiej kolejności je wypróbowywać. Animacje są kolejnym częstym źródłem problemów, więc rozważ wyłączenie ich w środowiskach testowych.

Przyczyna 5: Usługi i sieci zewnętrzne

Jeśli test wywołuje prawdziwego dostawcę płatności lub interfejs API strony trzeciej, jego wynik zależy od limitów czasu pracy i stawek innej osoby. W przypadku większości testów kpij z tych wywołań i prowadź niewielką liczbę oddzielnych kontroli kontraktów w porównaniu z rzeczywistą usługą, abyś nadal wiedział, czy się zmieni. W naszym przewodniku po testowaniu jednostkowym i integracyjnym wyjaśniamy, jak je podzielić.

Jak zdiagnozować niestabilny test

1. Potwierdź. Uruchom test wiele razy bez zmian. Z pytestem działa prosta pętla powłoki, a wtyczka taka jak pytest-repeat daje --count=100.
2. Zapisz dowody. Zapisuj dzienniki, zrzuty ekranu i ślady każdej awarii. Szczególnie przydatna jest tutaj przeglądarka śladów Playwrighta.
3. Podkreśl warunki. Uruchom go z ograniczonym procesorem, równolegle lub w kolejności losowej. Częstsze niepowodzenia ułatwiają naukę.
4. Przetestuj sam. Jeśli zawsze przechodzi pomyślnie samodzielnie, ale kończy się niepowodzeniem w pakiecie, podejrzewaj stan współdzielony.
5. Poszukaj wzorców. Sprawdź, które maszyny, pory dnia i sąsiednie testy są zaangażowane.
6. Sprawdź produkt. Zapytaj szczerze, czy w Twojej aplikacji może to być prawdziwy stan wyścigowy.

Czy automatyczne ponowne próby są rozwiązaniem?

Ponowne próby stanowią użyteczną krótkoterminową siatkę bezpieczeństwa i nie stanowią lekarstwa. Pojedyncza automatyczna ponowna próba w CI może kontynuować pracę podczas badania, ale test, który wymaga ponownej próby, aby przejść pomyślnie, nadal coś ci mówi. Co gorsza, prawdziwy, sporadyczny błąd produktu, który kończy się niepowodzeniem w 20% przypadków, zwykle zostaje niezauważony podczas ponownej próby.

Stosuj ponawianie prób zgodnie z poniższymi zasadami: ogranicz je do jednej lub dwóch, zapisuj każdy test, który wymagał wykonania jednego testu, i traktuj tę listę jako listę rzeczy do zrobienia. Test zgłoszony jako „zaliczony przy ponownej próbie” powinien być traktowany jako problem do zbadania, a nie jako sukces.

Proces zespołowy do niestabilnych testów

1. Zmierz. Śledź, które testy zakończyły się niepowodzeniem, a następnie przekaż to samo zatwierdzenie. Może to pokazać wiele narzędzi CI i reporterów testów.
2. Kwarantanna. Przenieś potwierdzony niestabilny test z serii blokującej, aby przestał przeszkadzać wszystkim, ale wykonuj go dalej i śledź.
3. Wyznacz właściciela i termin. Kwarantanna bez terminu staje się po prostu cmentarzem.
4. Napraw lub usuń. Jeśli testu nie warto naprawiać, usuń go i sprawdź, czy nadal istnieje gdzie indziej.
5. Zapobiegaj. Przed połączeniem przeprowadź kilka nowych testów. Test, który kończy się niepowodzeniem raz na pięćdziesiąt serii, jest lepiej wykryty teraz niż za sześć miesięcy.

Traktuj niestabilny test jako błąd z priorytetem, a nie jako szum tła. Ważność i priorytet mają tu również zastosowanie, zgodnie z opisem w ważność a priorytet. Jeśli niestabilność jest powszechna, przeczytaj o szerszych błędach automatyzacji testów i zastanów się, czy nie masz zbyt wielu testów na poziomie przeglądarki.

Podsumowanie

Niestabilne testy wydają się przypadkowe, ale rzadko takie są. Prawie każdy sprowadza się do założenia dotyczącego czasu, porządku, danych lub środowiska, które nie zawsze jest prawdziwe. Wybierz w tym tygodniu test, który najczęściej kończy się niepowodzeniem. Uruchom go pięćdziesiąt razy, znajdź założenie i napraw to na dobre. Jedna prawdziwa poprawka uczy zespół więcej niż sto powtórek.

Najczęstsze pytania

Ucz się dalej