Odpowiedź.

Flaky testy to testy, które mogą przechodzić lub padać bez zmian w kodzie, z powodu przypadkowych czynników zewnętrznych. Podkopują one zaufanie do automatyzacji i utrudniają procesy CI/CD.

Historia pytania: Napięcia związane z flaky testami pojawiły się wraz z masowym wprowadzeniem testów E2E, integracyjnych i UI, gdy stabilność otoczenia i zależnych usług nie była gwarantowana. Początkowo takie awarie ignorowano lub "ręcznie uruchamiano ponownie".

Problem:

Flaky testy sprawiają, że automatyczne przeprowadzanie testów jest niepewne.
Programiści zaczynają pomijać prawdziwe awarie, uznając je za fałszywe.
Rosnący czas wsparcia testów i potrzeba ręcznej analizy niestabilnych wyników.

Rozwiązanie:

Oddzielne śledzenie flaky testów. Oznaczenie (np. @FlakyTest) lub przeniesienie do osobnej kategorii.
Automatyczne ponowne uruchamianie. W przypadku awarii testu powtarzają go X razy — jeśli nie zawsze zawodzą, test jest oznaczany jako niestabilny.
Analiza przyczyn niestabilności: użycie logów, zrzutów stanu, monitorowania zasobów (np. niestabilna sieć, kolejki lub działanie GC).
Stopniowe poprawki: praca z otoczeniem testowym, uproszczenie scenariuszy, mockowanie niestabilnych zależności.

Przykład kodu dla automatycznego retry:

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # kod testu

Kluczowe cechy:

Ważne jest oddzielanie flaky testów od rzeczywistych awarii
Nie należy po prostu "retryować wszystkiego" — prawdziwe błędy nie powinny być pomijane
Regularnie analizowany i dokumentowany jest status testu, a nie ignorowany

Pytania z haczykiem.

Czy flaky testy to zawsze problem infrastruktury?

Nie, flaky mogą być spowodowane błędami logiki biznesowej, wyścigami w kodzie, asynchronicznością lub nieprawidłowym zarządzaniem czasem.

Czy wystarczy po prostu ponownie uruchomić nieudane testy?

Nie, retry tylko maskuje problem. Należy szukać i usuwać przyczynę.

Czy warto usuwać wszystkie niestabilne testy?

Nie, należy je tymczasowo izolować i naprawiać przyczyny, a nie po prostu na stałe wykluczać.

Typowe błędy i antywzorce

Ignorowanie flaky, co prowadzi do pomijania poważnych błędów.
Masowe retryowanie bez analizy przyczyn.
Oznaczanie ważnych testów jako flaky bez działań mających na celu ich poprawę.

Przykład z życia

Negatywny przypadek

W projekcie flaky testy po prostu oznaczano i więcej ich nie ruszano, uznając problem za "nierozwiązywalny".

Zalety:

Zmniejszenie liczby fałszywych "czerwonych" kompilacji

Wady:

Rzeczywiste błędy trafiają do produkcji
Ciągła ręczna weryfikacja wyników

Pozytywny przypadek

Dla każdego niestabilnego testu wprowadzono automatyczne ponowne uruchamianie i wewnętrzne śledzenie niestabilności. Prowadzono regularne wspólne przeglądy przyczyn i naprawiano błędy w miarę ich kumulacji.