Napisanie testów to połowa roboty. Druga połowa to sprawienie, żeby uruchamiały się same, przy każdej zmianie kodu, zanim cokolwiek trafi na produkcję. Właśnie po to są testy automatyczne w CI/CD: pipeline sam sprawdza, czy nowy commit niczego nie zepsuł, i mówi to zespołowi w kilka minut, a nie po tygodniu na środowisku klienta. U klientów widzę, że różnica między „mamy testy” a „testy pilnują nas w pipeline” to różnica między teatrem a realną siatką bezpieczeństwa.
Po co wpinać testy automatyczne w CI/CD
Testy uruchamiane ręcznie „jak ktoś pamięta” starzeją się w tydzień. Ktoś nie odpali, ktoś zignoruje czerwony wynik, ktoś dopisze feature bez testu. Pipeline usuwa czynnik ludzki: zestaw testów jest częścią procesu dostarczania, a nie dobrą wolą programisty w piątek po południu.
- Regresję łapiesz w minutach, gdy poprawka kosztuje kilka linijek, a nie po wdrożeniu, gdy kosztuje weekend.
- Zielony pipeline to warunek merge’a, więc na głównej gałęzi ląduje tylko kod, który przeszedł testy.
- Masz obiektywny sygnał jakości, nie „u mnie działa”, tylko wynik z czystego środowiska.
Gdzie uruchamiać testy: na PR, przy merge, nightly
Nie wszystko musi chodzić przy każdym pushu. Kluczem jest dobranie zestawu do momentu. Trzy poziomy, które sprawdzają się u większości zespołów:
Na pull request: szybki feedback
Przy otwarciu i każdej aktualizacji PR odpalaj to, co szybkie i deterministyczne: lint, testy jednostkowe, część integracyjnych. Cel to wynik w kilka minut, bo autor jeszcze pamięta, co pisał. Jeśli tu jest czerwono, kod nie idzie dalej.
Przy merge do głównej: pełniejszy zakres
Po scaleniu (albo tuż przed, na zmergowanym kodzie) uruchamiasz szerszy zestaw integracyjny i wybrane testy E2E na krytycznych ścieżkach. To pilnuje, że główna gałąź zawsze jest w stanie zdatnym do wdrożenia.
Nightly: to, co wolne i kosztowne
Pełny E2E przez UI, testy na wielu przeglądarkach, testy wydajnościowe (np. JMeterem w trybie CLI), dłuższe scenariusze, puszczaj w nocy. Nie blokują pracy w ciągu dnia, a rano masz raport. Wolniejszy feedback jest tu akceptowalny, bo to nie jest bramka do merge’a.
Piramida testów w CI
Klasyczna piramida testów przekłada się w pipeline wprost na czas i koszt. Im niżej, tym szybciej i taniej, i tym więcej testów. Odwrócona piramida (góra pełna wolnych E2E) to prosta droga do pipeline’u, który trwa godzinę i którego nikt nie chce oglądać.
| Warstwa | Ile | Szybkość | Kiedy w CI |
|---|---|---|---|
| Jednostkowe | Najwięcej | Sekundy | Każdy PR |
| Integracyjne / API | Średnio | Sekundy–minuty | PR / merge |
| E2E (UI) | Najmniej | Minuty | Merge / nightly |
Warstwę E2E trzymaj wąsko, tylko krytyczne ścieżki biznesowe (logowanie, zakup, płatność). Jeśli zastanawiasz się, co w ogóle automatyzować, a co zostawić człowiekowi, opisałem to w tekście o tym, czy wybrać testy manualne czy automatyczne. Do samego E2E warto też świadomie dobrać narzędzie, porównanie znajdziesz w artykule Selenium czy Playwright.
Flaky testy: jak nie zabić zaufania do pipeline’u
Flaky test to taki, który raz przechodzi, raz nie, przy tym samym kodzie. To najgroźniejszy problem CI, bo uczy zespół ignorować czerwony wynik („a, znowu ten test”). A gdy zignorują flaka, zignorują też prawdziwy błąd. Kilka rzeczy, które realnie ograniczają migotanie:
- Zero sztywnych
sleep: czekaj na warunek (element widoczny, odpowiedź API), a nie na sekundy. - Izolacja danych: każdy test tworzy i sprząta własne dane; testy nie mogą zależeć od kolejności.
- Selektory oparte na atrybutach testowych (np.
data-testid), a nie na kruchym XPath po strukturze DOM. - Mierz flakiness: oznaczaj testy, które migają, i traktuj je jak dług do spłaty, a nie do maskowania retry.
- Retry z umiarem: pojedynczy ponowny bieg bywa OK jako bufor, ale jeśli maskuje realny problem, tylko odsuwa awarię w czasie.
Fundamentem stabilnych testów jest zresztą dobrze napisany scenariusz, jasne kroki i jednoznaczny oczekiwany rezultat. Pokazuję to na przykładzie w tekście o tym, jak napisać dobry przypadek testowy.
Bramka jakości i wybór narzędzia
Bramka jakości (quality gate) to zestaw warunków, które kod musi spełnić, żeby przejść dalej. To ona zamienia testy z „informacji” w „regułę”. Typowo bramka wymaga: wszystkie testy zielone, pokrycie nie spadło poniżej progu, brak nowych krytycznych podatności z analizy statycznej. Ustaw ją na tyle rygorystycznie, by chroniła, i na tyle rozsądnie, by nie blokowała pracy bez powodu.
Narzędziowo nie ma jednej słusznej opcji. GitHub Actions i GitLab CI to dziś najczęstszy wybór, bo siedzą tuż przy repozytorium i konfiguruje się je plikiem YAML w projekcie. Jenkins wciąż mocno trzyma się w firmach z rozbudowaną infrastrukturą on-premise. Zasada jest prosta: bierz to, co jest najbliżej Twojego repo i procesu, migracja pipeline’u to koszt, którego zwykle nie warto ponosić dla samej mody.
I jeszcze jedno o szybkości feedbacku: pipeline, który trwa 40 minut, przestaje być narzędziem, a staje się przerwą na kawę. Zrównoleglaj testy, cache’uj zależności, dziel zestawy na etapy, tak, żeby developer dostał sygnał, zanim przełączy się na inne zadanie.
Jak w tym pomagam
Od 20 lat pracuję w IT, od siedmiu zajmuję się jakością oprogramowania i wielokrotnie wpinałem testy w pipeline’y różnej wielkości, od pojedynczego repo po rozbudowane procesy z wieloma etapami. Pomagam dobrać zakres testów do momentu (PR/merge/nightly), zbudować sensowną piramidę zamiast wolnego molocha, ujarzmić flaky testy i ustawić bramkę jakości, której zespół nie chce obchodzić. Robię to zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta. Zobacz zakres usług i jak wygląda współpraca. Jeśli chcesz iść dalej niż same testy, warto spojrzeć też na automatyzację procesów w n8n.