Testy poza CI szybko przestają mieć znaczenie
Testy uruchamiane ręcznie, kiedy ktoś sobie o nich przypomni, starzeją się po cichu. Po kilku tygodniach połowa nie przechodzi i nikt nie wie, czy to błędy w aplikacji, czy w testach. CI rozwiązuje ten problem, ale tylko wtedy, gdy zespół ufa wynikom i nie czeka na nie godzinami.
W jednym z moich projektów automatyczna regresja skróciła czas poświęcany na regresję o 80%. Same testy to połowa sukcesu, druga to moment, w którym się uruchamiają.
Dwa poziomy zamiast jednego wielkiego zestawu
| poziom | zawartość | kiedy | czas |
|---|---|---|---|
| Smoke | najważniejsze ścieżki | każdy pull request | kilka minut |
| Pełna regresja | wszystkie scenariusze | nocą albo przed releasem | ile trzeba |
Czasy w tabeli są orientacyjne. Zasada jest prosta: programista czeka na wynik przy każdym PR, więc smoke musi być krótki. Jeśli trwa zbyt długo, zespół zacznie go omijać.
Przykład w GitLab CI
Poniżej dwa zadania z Playwright. Testy smoke oznaczone tagiem @smoke idą przy każdym merge requeście, a pełna regresja według harmonogramu:
stages: [smoke, regression]
.playwright:
image: mcr.microsoft.com/playwright:v1.49.0-jammy
before_script:
- npm ci
artifacts:
when: always
paths: [playwright-report/]
smoke:
extends: .playwright
stage: smoke
script:
- npx playwright test --grep @smoke --reporter=html
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
regression:
extends: .playwright
stage: regression
script:
- npx playwright test --reporter=html
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"Wersja obrazu musi zgadzać się z wersją Playwright w projekcie. when: always zapisuje raport także wtedy, gdy testy nie przejdą, czyli właśnie wtedy, gdy jest najbardziej potrzebny. W Jenkinsie zasada jest ta sama: osobne zadania i zapisywanie raportów jako artefaktów.
Niestabilne testy
Test, który raz przechodzi, a raz nie, jest gorszy niż brak testu. Uczy zespół ignorować czerwony pipeline. Gdy wykryjesz taki test:
- Sprawdź przyczynę. Najczęściej to wyścig z asynchronicznym ładowaniem, zależność od kolejności testów albo współdzielone dane.
- Nie zwiększaj sztywnych opóźnień. Czekaj na konkretny stan, nie na upływ czasu.
- Wyłącz test na czas naprawy, ale z zapisanym zgłoszeniem i właścicielem.
Automatyczne ponawianie testów ukrywa problem. Jeśli go używasz, śledź, które testy przechodzą dopiero za drugim razem.
Dane i środowisko
Testy w CI uruchamiają się równolegle i bez nadzoru, więc nie mogą zależeć od ręcznie przygotowanego stanu. Twórz dane przez API przed testem, używaj unikalnych kont i sprzątaj po sobie. Sekrety trzymaj w zmiennych CI, a nie w repozytorium.
Co robić z wynikiem
Czerwony pipeline musi coś znaczyć. Ustalcie, że nieudany smoke blokuje scalenie, a wynik nocnej regresji ktoś przegląda rano. Bez właściciela raporty przestają być czytane. Prosty dashboard z trendem pomaga zauważyć, że liczba problemów rośnie, zanim stanie się to kłopotem przed releasem.
Podsumowanie
Dobra regresja w CI to krótki smoke przy każdej zmianie, pełny zestaw według harmonogramu, zero tolerancji dla niestabilnych testów i jasny właściciel wyników. Jeśli chcesz podłączyć swoje testy pod CI albo przywrócić zaufanie do istniejących, opisz swój projekt.