Test-Driven Development (TDD) – kiedyś promowane jako złoty standard nowoczesnego programowania – dziś coraz częściej traktowane jest z dystansem. Oczywiście jego fundamenty mają sens:
- zapewnia lepszą jakość kodu,
- zwiększa pokrycie testami,
- pozwala wcześniej wykrywać błędy,
ale w wielu współczesnych projektach okazuje się, że to nie kod jest najważniejszy w biznesie. Dlatego TDD nie zawsze się sprawdza.
I żeby nie było, że odradzam stosowanie TDD lub podważam jego zasadność – to świetne narzędzie, które przynosi wiele korzyści! Nie jest to też żaden hejt na TDD. Chcę jednak podzielić się swoimi doświadczeniami, dlaczego obserwuję spadek jego popularności i jak wygląda to w praktyce wielu zespołów.
1. TDD wymaga dobrze zdefiniowanych zadań i jasnej analizy biznesowej
Testy pisane przed kodem opierają się na konkretnych, jednoznacznych wymaganiach. W praktyce jednak zespoły często dostają zadania nie do końca sprecyzowane. Niejednokrotnie sam brałem udział w realizacji, gdzie w trakcie pracy wychodziły kolejne rzeczy do doprecyzowania.
TDD nie działa dobrze w takiej rzeczywistości – nie da się napisać dobrego testu bez dokładnego zrozumienia celu i oczekiwań. Często przed właściwym wdrożeniem trzeba zrobić prototyp, sprawdzić możliwości, a dopiero potem przejść do konkretnego rozwiązania.
Brak szczegółowej analizy biznesowej powoduje, że testy albo są nieadekwatne, albo blokują dalsze zmiany. A przecież codzienność to nie idealny świat z książki Kenta Becka – twórcy TDD – ani cukierkowe szkolenia, gdzie przykład jest doskonale opisanym kalkulatorem.
2. TDD jest czasochłonne – a czas to pieniądz
Pisanie testów w duchu TDD wymaga zatrzymania się, przemyślenia zadania, zaprojektowania architektury, rozpisania scenariuszy działania, wyjątków, przypadków brzegowych, integracji z innymi komponentami, strategii błędów, logowania…
To wszystko trzeba wykonać na starcie, zanim w ogóle powstanie kod.
I jasne – w wielu projektach bez TDD też się o tym myśli. Ale robi się to wtedy, kiedy dostarczony feature (konkretna wartość biznesowa z punktu widzenia klienta) ma sens.
TDD natomiast narzuca ten wysiłek zawsze, nawet przy najprostszych zadaniach.
Projekty muszą być dowiezione. Zespoły są rozliczane z dostarczonej funkcjonalności, a nie z liczby testów. Biznes i klient rzadko interesują się długiem technologicznym czy problemami z jakością kodu. Tymczasem TDD nie tylko wymaga więcej czasu na początku, lecz także podnosi koszty dowożenia.
Nie zliczę, ile razy byłem w sytuacji, gdy sprzedawca powiedział klientowi, że dany ficzer „już jest” – i trzeba go było na szybko dorobić. Więc szybko != TDD.
3. TDD nie sprawdza się w MVP, prototypach i projektach optymalizacyjnych
W projektach, gdzie często zmieniają się założenia – np. przy tworzeniu MVP, prototypach, rozwiązaniach badawczo-rozwojowych czy optymalizacyjnych – kluczowe jest szybkie dostarczanie wartości i testowanie hipotez. Budżety są ograniczone, a decyzje muszą zapadać błyskawicznie.
Gdy masz do dyspozycji 100 000 zł i musisz zrealizować cel w sposób jak najbardziej efektywny i efektowny, to wykorzystanie TDD zwyczajnie nie jest optymalnym podejściem.
Nie ma sensu pisać rozbudowanej warstwy testów pod coś, co może zostać wyrzucone lub zmienione po tygodniu. W tego typu projektach liczy się eksploracja i elastyczność, a nie rozbudowana dokumentacja testowa na przyszłość.
4. Wysoka dynamika biznesowa „zabija” TDD
Niektóre projekty muszą nadążać za błyskawicznie zmieniającym się rynkiem – wymogi zmieniają się co tydzień (albo i kilka razy dziennie, „bo klient zadzwonił”). Produkt przechodzi kolejne pivoty, a zespół nieustannie dostosowuje się do nowych potrzeb użytkowników.
W takiej dynamice TDD generuje dodatkową pracę: testy trzeba ciągle zmieniać, dostosowywać, aktualizować. Zamiast wspierać rozwój, stają się one balastem – dokumentują coś, co już nie istnieje. Zespoły szybko się zniechęcają, bo TDD po prostu nie nadąża za rzeczywistością.
Jak będą wyglądały nowoczesne testy?
Coraz większą rolę zaczynają odgrywać narzędzia wspierane przez sztuczną inteligencję, które automatycznie generują testy na podstawie kodu. Mam do nich jednak mieszane uczucia, ponieważ testy powinny przede wszystkim odzwierciedlać przypadki biznesowe, a nie jedynie strukturę w kodzie. Z drugiej strony, przy bardzo szybkich zmianach wymagań biznesowych, takie rozwiązania mogą okazać się skuteczne – ale to już temat na inny artykuł!
Pojawiają się również narzędzia potrafiące tworzyć zestawy testów na podstawie logów lub interakcji użytkowników, co może znacząco zmniejszyć konieczność ręcznego pisania testów. Rolą programisty byłaby wtedy głównie ich weryfikacja.
Oczywiście taki obrót spraw może nieść ryzyko spadku jakości. Trzeba jednak pamiętać, że istnieje wiele projektów opracowanych wręcz perfekcyjnie, które nigdy nie ujrzały światła dziennego. Zdarza się natomiast, że konkurencja wprowadza produkt może nieco mniej dopracowany, ale za to szybciej i dokładnie wtedy, gdy jest on najbardziej potrzebny.
Podsumowanie
TDD to świetna koncepcja, ale nie zawsze praktyczna. W wielu przypadkach bywa wręcz zgubna: zajmuje sporo czasu, ogranicza elastyczność i generuje dodatkowe koszty w projektach, które powinny być szybkie i lekkie. To narzędzie, nie religia – i jak każde narzędzie, warto je dobierać do konkretnego kontekstu.
TDD to przede wszystkim kultura pracy. Możesz w pojedynkę próbować praktykować TDD, pisząc najpierw testy, a potem kod, ale pełen potencjał tej metody ujawnia się dopiero w zespole, który faktycznie pracuje w tym stylu.
TDD wymaga świetnego zrozumienia biznesu. To biznes powinien prowadzić kod, nie odwrotnie. Dlatego stawianie metodologii i filozofii (jaką jest TDD) ponad specyfikę projektu często kończy się klapą. W świecie dynamicznych projektów, ograniczonych budżetów i nieustannych zmian – warto postawić na pragmatyzm i elastyczność. Bo to, co działało 10 lat temu w dużym zespole bankowym, niekoniecznie sprawdzi się dziś w startupie, który jutro może zmienić kierunek o 180 stopni.
Jeśli nie zgadzasz się z moimi doświadczeniami – luz, nie ma co podnosić ciśnienia. TDD swoje najlepsze lata ma już za sobą i powoli zmierza ku wygaszeniu. Nie ma sensu robić o to sporu😊
