Odpowiedź.

Mechanizm ponownego wykonywania testów (retry) wprowadza się w celu zwiększenia stabilności pipeline'a testowego i walki z flaky testami, ale wymaga rozsądnego podejścia.

Historia pytania Pojawił się jako workaround dla tymczasowych błędów infrastrukturalnych lub flaky, niezwiązanych z błędami aplikacji (niestabilne środowisko, problemy sieciowe, losowe timeouty API). Wiele systemów CI/CD obecnie wspiera wbudowany retry.

Problem Nadmierny lub niekontrolowany retry może ukrywać rzeczywiste błędy lub zamieniać awarie w "po prostu tymczasowe zjawiska". Pojawiają się fałszywie pozytywne rezultaty: wydaje się, że test przeszedł, ale błąd wciąż występuje.

Rozwiązanie Włączaj retry tylko dla testów niestabilnych lub zależnych od zewnętrznych systemów, używaj tagów lub znaczników. Ustalony limit powtórzeń (1-2 razy). Loguj wszystkie awarie i sukcesy powtórnych uruchomień w celu analizy przyczyn awarii.

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # Test, który może się nie udać z powodu niestabilności API
    ...

Kluczowe cechy:

Stosować punktowo i świadomie
Zawsze analizować przyczyny powtórzeń
Nie maskować błędów aplikacji, a tylko te infrastrukturalne/flaky

Pytania z pułapką.

Czy można uruchomić ponownie wszystkie testy automatyczne w pipeline?

To zła praktyka: maskują się zarówno rzeczywiste błędy, jak i problemy architektoniczne testów. Retry to ostateczność dla niektórych rodzajów testów.

Co zrobić, jeśli po 3 ponownych uruchomieniach test wciąż nie przechodzi?

Zatrzymać uruchamianie i otworzyć bug na niestabilność/śledztwo — w ten sposób ujawniają się tricky błędy, które wymagają refaktoryzacji.

Jeśli test przechodzi za drugim razem — to znaczy, że wszystko jest w porządku?

Nie, jedynym poprawnym stanem jest stabilne przechodzenie za pierwszym razem. Przechodzenie za drugim razem to wskaźnik problemu (flaky lub infrastruktura).

Typowe błędy i anty-wzorce

Niekontrolowane stosowanie retry, które ukrywa błędy
Brak analizy przyczyn awarii
Używanie retry zamiast naprawy rzeczywistych problemów

Przykład z życia

Negatywny przypadek

Dla całego pipeline'a Jenkins włączono globalny retry na dwa uruchomienia. Po miesiącu błędy spowodowane warunkami wyścigu w kodzie się rozciągnęły, a zespół uważał, że "jakość jest w porządku". Produkt nagle zaczął padać w produkcji z powodu tych samych błędów.

Zalety:

Były zielone pipeline'y

Wady:

Błędy aplikacji nie były ujawniane na czas
Przy dochodzeniach trudno było zrozumieć źródło niestabilności

Pozytywny przypadek

Dla kategorii testów z zewnętrznymi API skonfigurowano retry tylko dla nich (wg tagów). Wszystkie pozostałe testy przechodzą ściśle z jednego uruchomienia. Po logach zespół prowadzi śledztwa i rejestruje powtarzające się niepowodzenia.