Test-Driven Development Przekierowano ze strony: TDD

Twórcą metody jest Kent Beck, twórca programowania ekstremalnego i jeden z sygnatariuszy Manifestu Agile. Oświadczył on w 2003, że TDD zachęca do stosowania prostych projektów i budzi w ludziach pewność siebie. Test-Driven Development jest związany z pierwszymi koncepcjami programowania ekstremalnego rozpoczętych w 1999, ale ostatnio stał się samodzielną metodą.

TDD może być stosowane zarówno przez pojedynczych programistów, jak i przez całe zespoły. Pytaniem fundamentalnym jest jednakże kiedy można stosować tę metodykę. Chciałoby się powiedzieć – zawsze. Praktyka jednak pokazuje, że nie ma sensu korzystać z TDD w przypadku krótkich, kilkulinijkowych projektów. W takiej sytuacji nadmiarowość czasu jest po prostu zbyt duża. Nie ma również większego sensu korzystanie z tej metody w przypadku aplikacji, które nigdy nie będą rozwijane. W codziennej pracy okazuje się jednak, że praktycznie każdy projekt warto rozwijać za pomocą TDD.

Rozwijanie

Generalną zasadą TDD jest pisanie testów jednostkowych przed tworzeniem właściwego kodu. Jak pokazuje praktyka, nie ma większego sensu tworzenie testów jednostkowych do istniejącego kodu (jakość takich testów zazwyczaj jest bardzo niska), zatem pozostaje w istniejących projektach tworzenie testów jednostkowych do nowej funkcjonalności oraz korzystanie z pełni dobrodziejstw Test-Driven Development w nowych projektach.

Test Driven Development, czyli TDD, to technika tworzenia oprogramowania sterowana przez testy. Tworzenie kodu składa się z wielokrotnie wykonywanych trzech głównych kroków:

• Stworzenie testu jednostkowego
• Implementacja funkcjonalności
• Refaktoryzacja

Stworzenie testu jednostkowego

Pierwszy krok to przygotowanie takiego testu, który będzie testował funkcjonalność, którą będzie można dopiero tworzyć. To daje czas na przemyślenie interfejsu tej funkcjonalności oraz pozwala skupić się nad tym, czego tak naprawdę oczekuje się od implementowanej później funkcjonalności. Czas poświęcony na tworzenie testu skutecznie zmusza programistę do sprecyzowania problemu, z jakim ma się zmierzyć.

Implementacja funkcjonalności

Drugi krok to implementacja funkcjonalności. Dopiero mając test, przechodzi się do implementacji funkcjonalności. Co ważne, wprowadzane zmiany nie mogą naruszać innych testów, dzięki czemu mamy pewność, że nowo tworzona funkcjonalność nie zaburza tej już istniejącej.

Refaktoryzacja

Trzeci krok to refaktoryzacja, czyli uporządkowanie kodu, doprowadzenie go do stanu zgodnego ze standardami dobrego kodowania. Zmiany wprowadzane podczas refaktoryzacji nie mogę powodować błędów w wykonaniu zarówno testu jednostkowego z pierwszego kroku, jak i tych, które powstały wcześniej. Jest to pierwszy etap, na którym testy jednostkowe zaczynają pokazywać swoją potęgę – jeżeli jakakolwiek zmiana wprowadzona w kodzie powoduje, że jeden lub więcej testów przestaje działać, to wprowadzona zmiana najprawdopodobniej generuje błąd.



Metodologia TDD posiada dwie główne wady:

• TDD wymaga dodatkowego czasu na stworzenie testów jednostkowych - może być to bardzo zniechęcające dla kierownictwa, szczególnie w początkowym okresie korzystania z TDD, kiedy deweloper potrzebuje czasem nawet do 30% więcej czasu na wykonanie tych samych zadań. Z czasem jednak, po nabraniu płynności w pisaniu testów, ten dodatkowy czas zmniejsza się, dzięki czemu koszt stosowania tej metodologii maleje.
• TDD wymaga czasu w na utrzymanie testów - wynika to z faktu, że aby testy były użyteczne, muszą być odpowiednio zarządzane i uaktualniane wraz ze zmianami logiki aplikacji. Dopóki dodaje się nową funkcjonalność, problem ten praktycznie nie istnieje, jednak przy wprowadzaniu zmian w istniejącej funkcjonalności należy pamiętać, że potrzebny jest czas na odpowiednie zmodyfikowanie istniejących testów jednostkowych.

Zalety:

• Szybkie wychwytywanie błędów - już w momencie tworzenia oprogramowania wiele błędów można wychwycić za pomocą tej metodologii. Nie jest to bez znaczenia, ponieważ każdy błąd z czasem „nabiera wartości” a im później błąd zostanie wykryty, tym więcej osób angażuje i tym więcej kosztuje zarówno w aspekcie czasu, jak i pieniędzy. Wobec tego ważnym jest, aby wszystkie błędy były wychwytywane możliwie najszybciej i jak najbliżej programisty. Błędy wykryte przez autora kodu i poprawiane na bieżąco kosztują niewiele, ponieważ angażują tylko jedną osobę. Błędy wykryte przez zespół angażuje już czas zarówno programisty, jak i testera (lub testerów), co znacząco podwyższa koszty.
• Przemyślany kod - ponieważ w pierwszym kroku tworzony jest kod, który będzie wykorzystywał tworzoną funkcjonalność (test), to zazwyczaj naturalnie ten kod jest bardzo prosty i elegancki. Tak stworzony test wymaga, aby tworzona klasa była schludna i prosta do wykorzystania. Jest to efekt, który bardzo łatwo się osiąga – bez dodatkowego nakładu pracy – a przy okazji bardzo cenny szczególnie dla początkujących programistów.
• Możliwość przetestowania funkcjonalności bez uruchamiania całego oprogramowania – tworzony kod można uruchamiać częściowo, bez uruchamiania całej aplikacji. Nie ma to szczególnego znaczenia w małych projektach, ale już przy średnich i dużych czas jest niezwykle istotny. Za pomocą kilku kliknięć myszy, nie wychodząc z ulubionego środowiska programistycznego, można uruchomić części aplikacji i otrzymać miarodajne wyniki i to bez żmudnego uruchamiania kodu, bez męczącego przeszukiwania aplikacji i bez tracenia czasu na ponowne koncentrowanie się na istotnym problemie. Test jednostkowy pozwala w ciągu kilku sekund odpowiedzieć na pytanie, czy dany kawałek kodu będzie działał tak, jak chciał tego programista.