5 powodów dla których warto stosować TDD

Co to jest TDD i kiedy warto z niego korzystać? Jakie korzyści płyną z wykorzystania tego podejścia dla klienta? Te wszystkie informacje zawarłem w artykule.

Co to jest TDD?

Test Driven Development (TDD) to technika tworzenia oprogramowania, która jest coraz częściej stosowana przez małe i duże firmy. Przy tej metodyce, najpierw pisane są testy, a dopiero później funkcjonalność, którą chce mieć klient. Takie podejście zapewnia nam duże pokrycie kodu testami (ang. test coverage), co w dużej mierze zapewnia mniej błędów pojawiających się w programie.

TDD opiera się na 3 krokach, które są wielokrotnie powtarzane, aż do momentu osiągnięcia celu. Są to:

• pisania testów
• implementacji funkcjonalności
• refaktoryzacji kodu

Pisanie testów

Programista lub tester, pisze test sprawdzający działanie nowej funkcjonalności. W tej fazie na podstawie ustaleń z klientem lub zespołem deweloperów tworzymy testy. Wypisujemy kilka przypadków testowych, które pozwolą nam później określić czy implementacja funkcjonalności jest poprawna.

Oczywiście uruchomienie testów w tym kroku pokaże nam, że w sumie to nic nie działa, bo testy nie przechodzą. Nie ma co się dziwić, bo właśnie o to chodzi. Przecież, nie napisaliśmy jeszcze ani jednej linii programu, która by robiła to co chcemy.

Po co to wszystko? – przejdźmy do następnej fazy.

Implementacja kodu

W tej fazie, mając już napisane wszystkie interesujące nas testy do danej funkcjonalności, programista zaczyna implementować pożądane działanie. Deweloperzy w tej fazie nie zmieniają testów, ale co jakiś czas uruchamiają je, aby sprawdzić czy ich funkcja zachowuje się w odpowiedni sposób. W trakcie trwania pisania kodu i zmian, niektóre testy przejdą pomyślnie, a inne nie.

Ta faza kończy się w momencie, gdy wszystkie przypadki testowe przeszły pomyślnie. To znaczy, że program działa tak, jak było to ustalone z klientem.

Refaktoryzacja

Po tym jak już wszystkie testy przejdą pomyślnie, następuje czas na refaktoryzację kodu, tj. jego zmianę, ale bez zmiany działającej funkcjonalności. Warto sobie zadać pytanie, po co zmieniać kod, skoro już testy przechodzą. Otóż podczas refaktoryzacji programiści optymalizują kod, zmniejszają ilości linii programu (o ile to możliwe), uproszczają algorytmy i dzielą program na mniejsze metody.

Dzięki tym krokom program jest przejrzystszy i podzielony na części, które można później wykorzystać. Często refaktoryzacja kodu zwiększa prędkość działania programu, a najważniejszym aspektem po refaktoryzacji jest łatwiejsze dodawanie nowych funkcjonalności.

Plusem podejścia TDD, jest fakt, że nie musimy bać się o zepsucie naszego programu, ponieważ naszym wyznacznikiem poprawności działania są istniejące testy.

Wady Test Driven Development

Pierwszą wadą, którą można zauważyć z poprzednich akapitów to zwiększony nakład pracy, zanim napiszemy funkcjonalność program. Szczególnie w pierwszej fazie projektu jest to duży demotywator, dla klienta, kierownictwa, a nawet dla programistów. Podejście TDD często wymaga dodatkowych spotkań z osobami piszącymi testy, aby dobrze zrozumieli idee projektu. W podejściu TDD testy mogą być utożsamiane z wymaganiami klienta i są tak pisane, aby sprawdzać te wymagania.

Najczęściej nie ma sensu stosowania TDD dla krótkich, kilku linijkowych programów, których nie mamy zamiaru rozwijać. Dodatkowy nakład czasu może nawet dwukrotnie wydłużyć czas ukończenia programu.

Dodatkowo TDD niejako wymusza rozpoczęcia od testów nie tylko w trakcie tworzenia nowych funkcjonalności, ale także podczas modyfikacji już istniejących. Zawsze powinniśmy zacząć od napisania, utworzenia nowych lub modyfikacji istniejących testów, a potem implementacji funkcjonalności. W innym przypadku testy stają się nieaktualne i nie spełniają swojej roli.

Zalety Test Driven Development

Główną zaletą TDD jest fakt, że posiadamy automatyczne testy. Przy każdej modyfikacji naszego kodu, w zasadzie od razu wychwytujemy błędy. Wiele złożonych systemów mających nawet tysiące linie kodu, często nie mają wystarczającej ilości testów.

Programiści podczas implementacji lub modyfikacji funkcjonalności, mają uproszczoną pracę, ze względu na szybką informację zwrotną. Dodatkowo rozumieją, jak system ma działać, a przecież jak nie rozumiesz, jak coś ma działać, to nie jesteś w stanie tego dobrze zaprogramować.

Testy w większości pokrywają wymagania klienta, szczególnie testy funkcjonalne, ponieważ zgodne są z wymaganiami postawionymi przez klienta.

Korzyści klienta przy wykorzystaniu TDD

Czy kolejność w jakiej piszemy program i testy ma znaczenie, skoro i tak na końcu klient widzi “ten sam efekt”? Dlaczego klient ma płacić programiście za pisanie testów?! – Przecież one nie dają nam żadnej funkcjonalności!

1. Stabilność aplikacji

Dobrze przetestowana aplikacja, nie przestanie działać w losowych momentach, z powodu banalnych przyczyn. Duża ilość błędów została wyłapana przez programistów w trakcie pisania kodu (dzięki posiadaniu testów).

2. Szybsze wdrażanie zmian i nowych funkcjonalności

Deweloperzy, w szybki sposób mogą dokonywać zmian, nie bojąc się o wpłynięcie na inne obszary aplikacji. Natomiast, jeżeli taka sytuacja nastąpi, programista od razu wie, że coś jest nie tak, ponieważ aplikacja po zmianach nie przeszła pomyślnie testów. Pozwala to na skupienie się tylko nad daną częścią kodu, a nie myśleniem o całej aplikacji.

3. Zmniejszenie kosztu wyłapania błędu

Znalezienie błędu przy stosowaniu TDD ma mały koszt, ponieważ większość z nich poprawione zostanie podczas implementacji funkcjonalności. Dobrze napisane testy jednoznacznie wskazują nam, gdzie znajduję się błąd w kodzie. W przypadku, gdy nie mamy testów, błędy mogą się dopiero ukazać w momencie, gdy użytkownikom aplikacji coś nie działa. Poza kosztami poprawy błędu możemy stracić wiarygodność naszych użytkowników oraz opinia o jakości produktu może się znacznie zmniejszyć.

4. Dobra dokumentacja projektu

W celu napisania testów należy dokładnie zapoznać się z wymaganiami klienta. Wymagania spisywane są w sposób bardziej lub mniej formalny, a także o różnej szczegółowości. Natomiast napisane testy bardzo często znaczą więcej dla programistów niż wiele stron wymagań, ponieważ są dla nich zrozumiałe i przede wszystkim używalne. Testy są niejako mostem komunikacyjnym pomiędzy klientem i jego wizją systemu, a tym co, musi wykonać programista po swojej stronie. Dzięki testom programiści rozumieją jak ma działać aplikacja.

5. Zwrot kosztów przy dużych projektach

O ile koszt w początkowej fazie projektu jest stosunkowo duży, porównując do projektów bez pisania testów, z czasem się zwraca. Wynika to z potrzeby na samym początku przygotowania systemów do testowania (Continous Integration), spisania wymagań z klientem, przepisania wymagań na testy i inne mechanizmy pozwalające na pracę z podejściem TDD.
Jednak dodanie nowej funkcjonalności lub zmiana wymagań klienta skutkuje tylko dopisaniem kilku testów lub modyfikacji istniejącego. Najważniejsze jest jednak to, że mamy pewność, że nie zepsujemy poprzednich funkcjonalności. A to pozwala nam utrzymać jakość aplikacji lub systemu i zaufanie użytkowników oraz budować z nimi długotrwałe relacje.

Podsumowanie

Test Driven Development ma zarówno wady i zalety. Do decyzji o wykorzystaniu podejścia TDD należy podejść indywidualnie. Każdy software house i każdy klient ma inny pomysł na to, jak tworzyć aplikację lub system. Szczerze polecam rozpoczynanie tworzenia aplikacji od testów, ale nie dajmy się zwariować. Najważniejsze to podjąć świadomą decyzję na podstawie wszystkich czynników, nie patrząc tylko dodatkowy koszt prac programistycznych na pisanie testów. Przy dużych projektach koszt ten zwraca się z nawiązką w późniejszych etapach.