TDD - co to jest i dlaczego warto go używać?

TDD, czyli Test Driven Development, to jeden modeli procesu rozwoju kodu i wytwarzania oprogramowania. Proces zgodny z wytycznym TDD skupia się na częstym testowaniu kodu. Kładzie nacisk na tworzenie wszystkich możliwych scenariuszy testów jeszcze przed rozpoczęciem prac nad kodowaniem oraz aktualizowanie ich do nowych potrzeb produktu.

TDD - pisanie testu do nieistniejącego kodu 

Test Driven Development zakłada zupełną zmianę podejścia do testowania kodu. W największym skrócie technika ta polega na pisaniu testów do nieistniejącego kodu, oraz późniejszym dopisywaniu kodu w zgodności z testami i jego refaktoryzajcę.

Sposób działania TDD wywodzi się z założenia, że wcześniejsze wykrycie błędów pozwoli oszczędzić czas na ich usuwaniu. Model ten opiera się także na koncepcji, według której najpierw należy zbadać sposób działania kodu i jego możliwe scenariusze, a dopiero później – jeżeli okażą się one poprawne – wyprodukować na ich podstawie właściwy kod.

Code & Fix vs Test Driven Development

TDD jest zupełnym przeciwieństwem techniki Code & Fix, znanej także jako Debug Later Programming. Code & Fix jest bardziej naturalnym sposobem myślenia o programowaniu, a ze względu na swoją przystępność, często stanowi podstawowy schemat myślenia na początkowych etapach nauki programowania. 

Debug Later Programming zawiera 4 podstawowe fazy:

1. pisanie kodu
2. próba uruchomienia kodu
3. otrzymanie rezultatów:  kod działa, bądź nie działa
4. reakcja: szukanie błędu i eliminowanie go

Jak widać, nie jest to system pozbawiony wad. Postępowanie według wytycznych Code & Fix sprawia, że pomiędzy powstanie błędu, a jego wykryciem, może minąć dużo czasu. Im więcej czasu minie od jego pojawienia się, do rozpoznania go, tym więcej kodu można nadbudować na błędzie. W takich przypadkach debugowanie kodu bywa uciążliwe i czasochłonne.

Czas to pieniądz, zwłaszcza w projektach komercyjnych, w których masz zobowiązania wobec klienta. Zbyt późne wykrycie błędu sprawi, że do jego terminowego naprawienia będziesz potrzebował więcej roboczogodzin deweloperów, co znacznie zwiększy koszty projektu. Jeżeli jednak zmobilizowanie dodatkowych programistów nie wchodzi w grę, bądź zespół nie zdąży w porę pozbyć się problemu, będziesz musiał liczyć się z karami umownymi związanymi z opóźnieniem.

Najgorszym scenariuszem jest jednak niewykrycie błędu przez Twój zespół. W takim wypadku może okazać się, że w ręce klienta zostanie oddany wadliwy produkt, co negatywnie wpłynie na Twoją reputację.

Jak działa TDD:

TDD jest usystematyzowaną techniką, która opiera się schemacie złożonym z trzech prostych kroków:

1. RED — napisanie i sprawdzenie testu bez istniejącego kodu
2. GREEN — napisanie prostego kodu w zgodności z danym testem i przetestowanie nowego kodu
3. REFACTOR – refaktoryzacja istniejącego i działającego kodu po upewnieniu się, że jest on prawidłowy

Pozwalają one usystematyzować pracę nad projektem. Prawidłowo przeprowadzony projekt oparty na tym schemacie powinien wyglądać następująco:

RED — napisanie i sprawdzenie testu bez istniejącego kodu

Jeśli chcesz dodać nową funkcjonalność, pierwszym etapem jest napisanie i przeprowadzenie testu, jeszcze zanim powstanie nowy kod. Ze względu na to, że żadna funkcjonalność nie została jeszcze zaimplementowana, test nie powinien się powieść - dlatego ten etap prac nazywa się RED.

GREEN — napisanie prostego kodu w zgodności z danym testem i przetestowanie nowego kodu

Po sprawdzeniu testu przyszedł czas na napisanie prostego kodu i wprowadzenie nowych funkcjonalności. Na tym etapie nie skupiaj się na rozbudowywaniu kodu — zamiast tego postaraj się stworzyć jego podstawową wersję, za pomocą której sprawdzisz, czy Twój kod działa.

Nadszedł czas na przeprowadzenie testu po raz drugi: test powinien się powieść.

REFACTOR – refaktoryzacja istniejącego i działającego kodu po upewnieniu się, że jest on prawidłowy

Twój kod działa — to świetnie, ale to dopiero pierwsza część sukcesu. Teraz skup się na jego skalowalności, kierując się założeniami SOLID i zasadami tworzenia czystego kodu. Podczas refaktoryzacji kodu często wracaj do poprzedniego etapu i regularnie przeprowadzać testy, aby upewnić się, że nie popełnisz po drodze żadnego błędu.

Co teraz? Zgodnie z wytycznymi TDD, powtarzaj powyższe kroki na każdym etapie tworzenia kodu, w którym dodajesz, bądź modyfikujesz cokolwiek w swoim projekcie.

Czy to konieczne? Tak i nie.

Tworzenie kodu w oparciu o technikę TDD może brzmieć jak żmudne i pracochłonne zadanie Czy sprawi, że będziesz marnować czas, który możesz poświęcić na programowanie? Czasami rzeczywiście może okazać się to prawdą — testy nie wykażą żadnych błędów, a proces wytwarzania oprogramowania od początku do końca przebiegnie bez zastrzeżeń.

Jednak kiedy dzięki testom w porę znajdziesz błąd i oszczędzisz mnóstwo czasu na jego poprawianiu, zrozumiesz jak wartościową techniką jest TDD.

TDD — kiedy unikać tej techniki?

TDD jest złożonym narzędziem, które  w odpowiednich warunkach może ułatwić, uprościć i usprawnić proces rozwoju kodu. Jednak tak samo jak inne narzędzia, sprawdzi się wyłącznie w określonych warunkach. Programowanie to nie biwak, podczas którego “nożołyżkowidelec” rozwiąże wszystkie Twoje problemy. 

W jakich sytuacjach nie sprawdzi się model TDD?

• Kiedy Twój projekt nie jest złożony i nie widać przesłanek ku temu, że w najbliższym czasie pojawi się konieczność jego skalowania. W takim wypadku pisanie licznych scenariuszy testów nie przyniesie oczekiwanych rezultatów, ponieważ bez problemu będzie można je zwizualizować bez pomocy testów.
• Jeżeli nie masz pewności, jak rozwiązać dany problem. W takim wypadku lepiej najpierw naszkicować i zakodować swój pomysł. Takie rozwiązanie sprawi, że lepiej zrozumiesz swój problem i zrozumiesz, jak go naprawić. Dopiero wtedy przyjdzie czas, aby przeprowadzić testy wydajnościowe. W tym wypadku technika TDD mogłaby tylko spowolnić proces, jednak nawet bez niej, refaktoryzacja i testy jednostkowe są konieczne

TDD nie oznacza sprawdzania każdej pojedynczej rzeczy w twoim kodzie. Testowanie każdej trywialnej zmiany pochłania dużo czasu i przynosi niewiele wartości. Dlatego też, w procesie programowania dobrze kierować się elastycznością tak, aby dostosować technikę pracy do swoich potrzeb. Jeżeli nie widzisz potrzeby testowania, po prostu zacznij kodować.

TDD – jakie są zalety tej techniki?

Teraz kiedy rozumiesz, w jakich sytuacjach warto zrezygnować z TDD, nadszedł czas, aby przyjrzeć się najważniejszym zaletom tej techniki.

TDD minimalizuje ryzyko wystąpienia błędów w aplikacji. Poprzez pisanie testów wybiegających w przyszłość, unikniesz zakodowania wielu błędów i nie będziesz musiał zajmować się ich usuwaniem na późniejszych etapach. 

Taki zabieg oszczędzi nie tylko twój czas, ale także nerwy – w szczególności podczas pracy nad bardziej złożonymi projektami. Dzięki TDD upewnisz się, że każda pojedyncza linijka kodu jest potrzeba w projekcie. To sprawia, że programiści nie piszą niepotrzebnych, nadmiarowych linijek kodu, a dwie najważniejsze zasady, “KISS” (Keep It Stupid Simple ) i “DRY” (Don't Repeat Yourself), są zachowane

Przemyślana refraktoryzacja kody jest łatwiejsza i szybsza niż jego późniejsze naprawianie i upraszczanie w biegu, co ma znaczenie zwłaszcza w przypadku długoterminowych projektów. Dzięki temu już na wcześniejszym etapie prac dowiesz się, czy twój kod zadziałał tak, jak powinien,

Dobrze przeprowadzone testy są także dokumentacją twojej pracy. To oszczędza konieczność poświęcania czasu na pisanie i aktualizowanie dokumentacji i raportów. Zamiast tego, możesz po prostu udostępnić folder ze swoimi testami, a inni członkowie zespołu szybko zorientują się w postępie prac nad projektem.

TDD – praktyka, praktyka i jeszcze raz praktyka

Programowanie z wykorzystaniem techniki TDD może być proste – wystarczy wyrobić sobie odpowiednie nawyki. Jeżeli raz nauczysz się korzystać z tego modelu, zawsze będziesz mógł do niego wrócić. Aby przyspieszyć naukę, powinieneś wziąć pod uwagę kilka rzeczy: 

• Unikaj niepotrzebnego zwiększania zakresu testów: częste testowanie i niewielkie zakresy testów sprawią, że ich wyniki będą bardziej czytelne, a debugowanie kodu łatwiejsze.
• Nie bój się dużej liczby testów: podczas pracy z techniką TDD przeprowadzisz naprawdę dużą ilość testów. Nie przeraź się ich objętością i pamiętaj o tym, aby dbać o ich jakość i czytelność. Możesz podzielić je na poszczególne foldery w zależności od typu testu.
• Rozdzielaj testy: dobrą praktyką jest rozdzielanie poszczególnych sekcji kodu. Dlaczego nie zastosować tego samego zabiegu przy testach? Jeżeli twoje testy powstają niezależnie od kodu, to są bardzo złożone i mogą nieoczekiwanie zmienić swoje zachowanie. Być może spędzisz więcej czasu na ich debugowaniu. Twój wysiłek z pewnością przełoży się na łatwiejsze i mniej czasochłonne debugowanie właściwego kodu.

Podsumowanie

Ważne, aby zawczasu zrozumieć i zadecydować o tym,  jaki model wytwarzania oprogramowania będzie odpowiadał danemu projektowi. Warto pamiętać o TDD zwłaszcza wtedy, kiedy planujesz długoterminowe projekty, a kodowanie będzie bardziej złożone, a także zajmie dużo czasu i poszczególnych etapów pracy. Można zrezygnować z modelu TDD, kiedy nie ma planów na to, aby aplikacja, bądź projekt, rozrosły się w przyszłości.

Potrzebujesz wsparcia profesjonalnych testerów aplikacji? Postaw na Softnauts! Z naszą ofertą zapoznasz się poniżej:

•  Testowanie aplikacji