Czy na pewno stać Cię na zaniechanie pisania testów?

Autor: Adrian Gadzina

Testy to temat, który wciąż budzi kontrowersje. W wielu projektach IT ich brak tłumaczy się ograniczonym budżetem, krótkim czasem na wdrożenie czy przekonaniem, że „testowanie spowalnia rozwój”. Tymczasem rezygnacja z testów może kosztować znacznie więcej niż ich wdrożenie – zarówno w postaci błędów na produkcji, kosztownych poprawek, jak i braku pewności co do stabilności systemu.

Programista pracujący przy laptopie otoczony symbolicznie przedstawionymi błędami w postaci robaczków, na ekranie widoczny raport błędów — Każdy nieprzetestowany fragment kodu może generować nieprzewidziane błędy – czy naprawdę stać Cię na ich ignorowanie?

Koszt błędu rośnie wykładniczo — a testy to najtańszy sposób, żeby go złapać wcześnie

IBM Systems Sciences Institute oszacował, że koszt naprawy błędu wykrytego na produkcji jest 15-krotnie wyższy niż tego samego błędu złapanego w fazie developmentu. Przy bardziej złożonych systemach ten współczynnik rośnie do 100×. Mimo to wiele zespołów traktuje testy jako luksus — coś, na co „nie ma budżetu" albo co „spowalnia development". W praktyce jest odwrotnie: brak testów spowalnia wszystko, tyle że efekty widać z opóźnieniem.

„Nie mamy budżetu na testy" — a mamy budżet na naprawianie?

To najczęstszy argument. I najsłabszy. Kod bez testów działa — dopóki ktoś czegoś nie zmieni. A w żywym projekcie zmiany są codziennością. Każda nowa funkcjonalność, każdy bugfix to potencjalne źródło regresji, której nikt nie zauważy aż do momentu, gdy zgłosi ją użytkownik.

W raporcie DORA State of DevOps 2023 zespoły z wysokim pokryciem testami automatycznymi wdrażały zmiany 208 razy częściej niż zespoły o niskim pokryciu — przy jednoczesnym 3-krotnie niższym wskaźniku awarii po wdrożeniu. To nie korelacja — to mechanizm: testy automatyczne usuwają strach przed zmianą.

Nawet minimalne pokrycie — testy dla ścieżek krytycznych (logowanie, płatności, kluczowa logika domenowa) — drastycznie zmniejsza ryzyko. Nie trzeba zaczynać od 90% coverage. Trzeba zacząć.

Testy jako dokumentacja — lepsze niż komentarze

Badania Stack Overflow Developer Survey powtarzalnie pokazują, że programiści spędzają więcej czasu na czytaniu kodu niż na pisaniu. Dobrze napisany test jednostkowy mówi więcej o intencji funkcji niż komentarz w kodzie — bo komentarz może być nieaktualny, a test albo przechodzi, albo nie.

Test jako specyfikacja — test o nazwie should_reject_order_when_stock_is_zero dokumentuje regułę biznesową jednoznacznie. Nowy członek zespołu nie musi „rozgryzać" kodu — uruchamia testy i widzi, jakie zachowania system gwarantuje.
Onboarding — w projektach z testami czas wdrożenia nowego programisty jest krótszy. Może wprowadzać zmiany i od razu sprawdzać, czy nie złamał istniejących kontraktów.
Refaktoryzacja — bez testów refaktoring to zgadywanka. Z testami — czynność rutynowa. Zmieniasz implementację, uruchamiasz testy, patrzysz na wynik. Zielone? Idziesz dalej. Czerwone? Wiesz dokładnie, co się zepsuło.

Piramida testów — ile czego powinno być

Koncept Mike'a Cohna z 2009 roku, nadal aktualny. Poprawna struktura testów przypomina piramidę:

Testy jednostkowe (unit) — fundament. Szybkie (milisekundy), tanie w utrzymaniu, testują izolowaną logikę. Powinny stanowić 70–80% wszystkich testów.
Testy integracyjne — sprawdzają współpracę modułów: komunikację z bazą danych, API, kolejkami. Wolniejsze, ale weryfikują granice systemu. Około 15–20%.
Testy E2E (end-to-end) — symulują pełną ścieżkę użytkownika. Najwolniejsze i najdroższe w utrzymaniu. Powinny pokrywać tylko ścieżki krytyczne: 5–10%.

Częsty błąd: zespół pisze wyłącznie testy E2E (bo „testują wszystko"), a potem narzeka na wolny pipeline i kruche testy, które padają losowo. Odwrócona piramida — tzw. „ice cream cone" — to antywzorzec, który generuje więcej frustracji niż wartości.

CI/CD — testy mają sens tylko wtedy, gdy się uruchamiają

Test, który leży w repozytorium i nikt go nie odpala, jest bezwartościowy. Testy muszą być częścią pipeline'u CI/CD — uruchamiane automatycznie przy każdym pushu, przed każdym merge'em.

Pre-commit hooks — lintowanie i szybkie testy jednostkowe przed commitem.
CI pipeline — pełen zestaw testów (unit + integracyjne) uruchamiany na pull requeście. Blokujący — bez zielonych testów nie ma merge'a.
Staging environment — testy E2E na środowisku zbliżonym do produkcji, przed wdrożeniem.
Feature flags — nowa funkcjonalność włączana stopniowo, z możliwością natychmiastowego wyłączenia bez rollbacku.

W raporcie Puppet State of DevOps (2021) zespoły z w pełni zautomatyzowanym pipeline'em testowym miały 7-krotnie niższy MTTR (Mean Time to Recovery) po incydentach produkcyjnych.

Prawdziwe historie — czego uczy produkcja

W 2019 roku mBank wysłał powiadomienia push z błędnie zakodowanymi polskimi znakami diakrytycznymi. Klienci zobaczyli „zak³ócenia w dzia³aniu" zamiast poprawnego tekstu. Problem był trywialny technicznie — złe kodowanie UTF-8 na wyjściu — ale banalny test renderowania wiadomości push złapałby go przed wysyłką do milionów użytkowników.

To nie był jedyny taki przypadek. Knight Capital Group w 2012 roku stracił 440 milionów dolarów w 45 minut z powodu błędu we wdrożeniu kodu tradingowego — kodu, który nie przeszedł przez testy regresyjne, bo ich nie było. Firma zbankrutowała.

Od czego zacząć — plan na pierwszy tydzień

Dzień 1–2 — zidentyfikuj ścieżki krytyczne (logowanie, rejestracja, płatności, główna logika domenowa). Napisz testy dla nich.
Dzień 3 — skonfiguruj CI pipeline, który uruchamia testy przy każdym pushu. GitHub Actions, GitLab CI — narzędzie nie ma znaczenia, liczy się automatyzacja.
Dzień 4–5 — dodaj testy jednostkowe do modułu, w którym ostatnio był bug. To naturalny punkt startu: wiesz, co się zepsuło, więc wiesz, co testować.

Testy to nie koszt — to ubezpieczenie. A różnica między projektem z testami a projektem bez nich ujawnia się w momencie, gdy coś pójdzie nie tak. I zawsze coś pójdzie nie tak. Jeśli budujesz system dedykowany i chcesz mieć pewność, że testowanie jest wbudowane w proces od początku — porozmawiajmy.

Źródła

DORA — State of DevOps Report — coroczny raport o praktykach DevOps i ich wpływie na wydajność zespołów (Google Cloud).
IBM — Software Testing — dane o kosztach błędów w zależności od fazy wykrycia.
Martin Fowler — Test Pyramid — opis piramidy testów i prawidłowej proporcji typów testów.
Stack Overflow Developer Survey — coroczne badanie praktyk i nawyków programistów.
Puppet — State of DevOps Reports — dane o wpływie automatyzacji testów na MTTR i częstotliwość wdrożeń.