Test Driven Development – TDD to metodologia powstawania oprogramowania. Opiera się ona na koncepcie iteracyjności, gdzie mamy mikro, krótkie cykle rozwoju. Opierają się na tym, że zanim jeszcze powstanie właściwa funkcja, najpierw powstaje przypadek testowy, który później ma tę funkcję sprawdzić. Głównym celem tego założenia jest zapewnienie solidności i jakości dostarczanego rozwiązania.
Test Driven Development podąża zwykle cyklem Czerwony – Zielony – Refactor. Ten cykl wygląda tak, że zaczynamy od przygotowania pojedynczego testu. Uruchamiamy ten test i powinniśmy go w tym miejscu oblać (czerwone). Dlatego że nie ma jeszcze funkcji, która ten test miałaby przejść. Następnie piszemy dokładnie taki kod, aby ten test pojedynczy przejść. Uruchamiamy test. Jeśli mamy zielone, sprawdzamy co jeszcze mamy do uzupełnienia. Dalej następuje refaktoryzacja kodu, tak aby nadal wszystkie testy były zielone. Powtarzamy cały proces. To jest jeden cykl, jedna iteracja. A dlaczego tak ważne jest, aby ten pierwszy test został oblany? Dlatego że jeśli test zostałby zaakceptowany, jeśli byśmy ten test przeszli, oznaczałoby że mamy w systemie jakąś nieprawidłowość. Dlatego że nie ma jeszcze funkcji, która mogłaby zapewnić takie warunki w tym miejscu, aby test został spełniony. Jeśli jest oblany, to znaczy, że został dobrze przygotowany. Ten proces może się wydawać powolny, dlatego że przy każdym kawałku kodu, przy każdej jednej funkcji, funkcjonalności, którą chcemy w systemie wdrożyć, musimy za każdym razem przejść taki cykl. Jednak patrząc statystycznie na cały proces powstawania pełnego programowania, całego systemu, przyjmuje się, że jednak ten proces zapewnia większą szybkość. Dlatego że w takich krytycznych momentach, tam gdzie zwykle nie mielibyśmy stuprocentowego pokrycia testami, znalezienie kawałka kodu, który powoduje błąd bywa bardzo czasochłonne.
Korzyści płynące z metodologii Test Driven Development
Jakie są korzyści płynące z tej metodologii? Jest ich cała masa. Zaczynając od jakości kodu, co też przekłada się na to, że kod powstaje niejako bardziej modułowo. Jeżeli później mamy konieczność zmiany jakiegoś elementu systemu, dopisania czegoś, to dużo łatwiej się na takim systemie pracuje. Z racji tego, że kod powstaje w ustrukturyzowany sposób łatwiejsza jest też współpraca między poszczególnymi członkami zespołu. Najczęściej okazuje się też, że koszt takiego rozwiązania jest po prostu niższy ze względu na większą efektywność pracy zespołu. Ze względu na mniejszą ilość newralgicznych miejsc, w których mogły powstać błędy. Ze względu na łatwość integracji tego rozwiązania na przykład z innymi modułami systemu czy z innymi systemami. Generalnie jest to metodologia, która jest pożądana przez większość zespołów programistycznych, dlatego że też zapewnia lepszą jakość pracy. Rozwiązanie w tych krótkich cyklach iteracyjnych zdaje się powstawać trochę wolniej, jednak ostateczny wynik jest praktycznie zawsze lepszy. Przez to członkowie zespołu mają mniejszy poziom stresu, a większą pewność tego, co dostarczają.
Rodzaje Test Driven Development
Test Driven Development możemy następnie podzielić na dwie podkategorie: Inside-Out i Outside-In.
Inside-Out to jest podejście od strony programisty. Pokrycie testami kodu powstaje z punktu widzenia osoby tworzącej kod, a infrastruktura całego rozwiązania buduje się niejako organicznie z poszczególnych elementów, które programista tworzy. Jest to podejście łatwiejsze do nauczenia. Jednak niesie ze sobą pewne nieprawidłowości związane z subiektywnością dostarczanego rozwiązania.
Outside-In to jest dokładnie odwrotne podejście. Czyli tutaj zaczynamy od warstwy logicznej, biznesowej. Od czynników zewnętrznych, od naszego użytkownika. Patrzymy na to, co użytkownik może zrobić z tym elementem systemu i z tego miejsca piszemy testy. To podejście jest trudniejsze, ale zapewnia większą obiektywność dostarczanego systemu.
Obejrzyj film:
