Nie minęło wiele czasu od ostatniego wpisu, w którym relacjonowaliśmy nasze uczestnictwo w prezentacji Wujka Boba (Roberta Martina) o czystym kodzie, a już mieliśmy przyjemność wybrać się na kolejne spotkanie z serii. Tym razem tematem była technika Test-Driven Development (TDD), czyli tworzenie oprogramowania w oparciu o testy.
Przyzwyczajony do ekscentrycznych zachowań Wujka z pierwszej prezentacji, tym razem już nie odczuwałem, by jego rekwizyty czy zmieniająca się scenografia działały rozpraszająco – wręcz przeciwnie, odbierałem je jako ciekawe urozmaicenie. Całość prezentacji miała formę rozmowy Wujka Boba z Panem Spockiem, znanym z patrzenia na świat tylko przez pryzmat logicznego myślenia.
Wujek Bob starał się przekazać słuchaczom, w jaki sposób technika TDD prowadzi do poprawy jakości kodu źródłowego, szczególnie w większych projektach. Wskazał problem, jaki często dotyka programistów pracujących przy złożonych systemach, którzy obawiają się wprowadzania zmian w istniejącym (i działającym) kodzie, ponieważ zmiany mogą spowodować problemy. Gdy strach bierze górę, w projekcie pozostawiany jest kod gorszej jakości.
Zastosowanie rygorystycznych testów pozwala na wyeliminowanie tych obaw, ponieważ programista wprowadzający zmiany może je natychmiast przetestować i dzięki temu przekonać się, czy nie pojawiły się problemy. Warunek? Programista musi mieć pewność, że może zaufać swoim testom. By to osiągnąć, należy trzymać się trzech zasad:
- Przed napisaniem jakiegokolwiek kodu produkcyjnego, musi istnieć nieprzechodzący test, który zostanie przez ten kod naprawiony.
- Każdy test musi wykazywać określony brak lub błąd w systemie, i musi sprawdzać jedynie minimalny zestaw warunków, wystarczający do niepowodzenia.
- Zabronione jest pisanie większej ilości kodu produkcyjnego, niż wystarczająca do naprawienia jednego nieprzechodzącego testu.
Zalety płynące ze stosowania tej techniki są niezaprzeczalne – w dużych projektach TDD pozwala na bardziej efektywną pracę programistów, ułatwia kontrolę jakości, oraz (co już zostało powiedziane) zapewnia bezpieczne wprowadzanie zmian i poprawek w „starym” kodzie.
Nie będę zdradzać zakończenia prezentacji i tego, czy Wujkowi udało się przekonać Pan Spocka do swoich racji. Osobiście nabrałem chęci do wypróbowania TDD w formalny sposób i liczę na to, że w którymś z realizowanych w najbliższej przyszłości projektów będę mieć taką możliwość.