Test driven development

tdd

Ten wpis jest częścią serii o testach. Całość znajdziesz pod tym adresem.

Wstęp

O testach powiedzieliśmy sobie już całkiem sporo i myślę, że wiedza zawarta we wszystkich artykułach z cyklu, zapewni Ci solidne podstawy, które wykorzystasz w swojej nauce, a także w pracy. Wraz z każdym napisanym testem zwiększysz swoje doświadczenie w tej kwestii i poprawisz jakość tworzonego oprogramowania, a o to nam chodzi, prawda? 🙂 Jestem jednak pewien, że gdy stajesz przed wyborem pisania unit testów lub właściwych funkcjonalności często wygrywa ta druga. Tak, wiem rozwijanie programów to nasza praca i jest ona zdecydowanie ciekawsza niż pisanie do niej testów. Niemniej jednak często ratują one z wielu nieprzewidzianych problemów i są nieocenioną pomocą w rozwijaniu każdej aplikacji. Przyznam, że sam często się łapię na tym, że wolę rozwijać program niż pisać testy. Każdego, kto ma ten sam problem, zapraszam do lektury dzisiejszego artykułu – omówię w nim podejście, które zachęci Cię do testowania swojego kodu.

Podstawowe informacje

Test driven development (TDD) – to podejście, które chciałem Ci przedstawić. Zostało opracowane przez Kenta Becka i więcej informacji możesz znaleźć w jego książce: Test-Driven Development: By Example. W telegraficznym skrócie mógłbym powiedzieć, że jest to metodyka tworzenia oprogramowania, które zakłada, że zanim zaimplementujemy jakąś funkcjonalność, musimy napisać do niej testy. Autor dzieli całość na trzy-etapowe cykle, które postaram się opisać.

Red

Pierwszy etap to faza Red. Nazwa wywodzi się od koloru, który jest wyświetlany po uruchomieniu testów, bo ich uruchomienie ma zakończyć się niepowodzeniem! W myśl głównego założenia TDD zanim zaczniesz pisać właściwy kod powinieneś napisać do niego testy. Na początku więc będziesz musiał zastanowić się nad tym, jak będzie napisana Twoja funkcjonalność, jakie klasy do niej wykorzystasz, ile ich będzie, jak będą inicjalizowane, itp. Jest to moment, w którym podejmiesz wiele decyzji dotyczących projektu funkcjonalności. Bez stosowania TDD, w szczególności młodszym programistom, zdarza się podejmowanie takich decyzji w ostatnim momencie. Zaczynają (a ja nie byłem w tym podejściu wyjątkiem) programowanie z mglistą wizją końca, a w momencie pojawienia się jakiegoś problemu, wymyślają szybkie rozwiązanie, które często bywa tym nietrafionym, a skutkiem tego może być aplikacja, która zawiera tzw. spaghetti code i jest trudna w utrzymaniu i modyfikacji. TDD rozwiązuje ten problem. Jak? – zapytasz. A no właśnie założeniem, że zanim zaczniesz implementować musisz mieć testy. Zanim jednak je napiszesz, system będzie posiadał przemyślany zestaw pustych klas. Do nich właśnie należy napisać później testy, uruchomienie ich i czerwony kolor, to oznaka zakończenia tego etapu.

Green

Kolejna faza nosi nazwę Green, a jej głównym zadaniem jest szybka implementacja funkcjonalności. W tej części należy skupić się na sprawieniu, żeby testy przeszły, stąd nazwa. Wyrażenia szybka implementacja użyłem nieprzypadkowo. Z założenia faza Green nie powinna skutkować ostateczną wersją kodu, a jedynie taką, która spełnia swoje zadanie i sprawia, że testy po uruchomieniu świecą się na zielono. W tym etapie, często pomija się stosowanie wzorców projektowych i cały kod przypomina bardziej przygotowanie tzw. proof of concept niż właściwego kodu. Za to odpowiedzialna jest ostatnia faza.

Refactor

Przechodząc do niej jesteśmy na etapie, w którym:
– zaprojektowaliśmy funkcjonalność
– napisaliśmy do niej testy
– napisaliśmy wstępna wersję funkcjonalności

Do pełni szczęścia brakuje tylko tego, żeby kod wyglądał przyzwoicie i działał optymalnie. I to właśnie zadanie części refactor. Po jej zakończeniu, funkcjonalność, która miała być napisana jest gotowa. Jeśli nie znasz jeszcze pojęcia refactoring, w dużym uproszczeniu jest to proces, w którym modyfikuje się działający już kod, a właściwie często jego pierwszą wersję, tak, aby implementował wzorce projektowe, działał szybko i wydajnie, a także był schludny i estetyczny. Jeśli interesuje Cię ta tematyka, to gorąco polecam Ci książkę Roberta C. Martina – Czysty kod. Podręcznik dobrego programisty, znajdziesz w niej wiele przykładów i pomysłów na to, jak zmodyfikować swój kod zgodnie z ogólnie przyjętymi praktykami. Pozycja ta może przydać Ci się w trzeciej fazie TDD, która polega właśnie na refaktoryzacji.

Kilka linijek wcześniej wspomniałem, że ta faza odpowiada za przygotowanie ostatecznej wersji kodu. Oczywiście jest to prawda, jednak nie zawsze jedna iteracja serii red-green-refactor wystarczy, żeby zakończyć implementację. Może zdarzyć się, że w trakcie części green zauważysz, że test nie pokrywa pewnych przypadków lub postanowisz zmienić algorytm, z którego będziesz korzystać. Będzie to wymagało powrotu do fazy red, napisania nieprzechodzących testów i ponownego zajęcia się kodowaniem. Analogiczna sytuacja może się przytrafić podczas modyfikowania kodu. Najważniejsze to pamiętać o tym, żeby nie zostawiać kawałka kodu bez testów i stosować ogólny schemat postępowania w podejściu TDD. Reszta przyjdzie z doświadczeniem.

Korzyści

Okej! Omówiliśmy już sam proces narzucany nam przez test driven development, ale zastanówmy się przez chwilę, po co w ogóle to wszystko? Takie podejście niesie za sobą wiele zalet. Postaram się wymienić i opisać najważniejsze według mnie.

Organizacja procesu tworzenia kodu

TDD narzuca pewien schemat działania. Rozpoczynając przygodę z programowaniem często rzucamy się na wszystko naraz. Chcemy uczyć się kilku języków, różnych narzędzi, frameworków, itp. Podobnie jest z aplikacjami, które tworzymy. W głowie pojawia się jedynie zarys funkcjonalności jakie miałaby mieć, a ręce już wędrują na klawiaturę. Takie działanie niestety często prowadzi do bałaganu w kodzie. Stosowanie TDD pozwala ochłonąć i przemyśleć wszystko zanim zaczniemy kodowanie. Musimy zaprojektować to co chcemy napisać, stworzyć testy, a dopiero po tym właściwy kod. Widać tutaj regularność i powtarzalny proces, który bardzo sprzyja organizacji pracy i owocuje lepszą jakością całego rozwiązania jakie tworzymy. Co więcej, paradoksalnie, skraca to czas tworzenia. Oczywiście nie zaczynamy od kodowania, ale samo działanie jest bardziej przemyślane i wydajniejsze.

Zmusza do pisania testów i nauki testowania

Jak już wspomniałem, początkujący programiści często pomijają tworzenie testów w swoich aplikacjach. Zwykle znajdują ciekawsze zajęcia, co niestety często bywa brzemienne w skutkach. TDD usuwa ten problem. Stosowanie go zmusza do napisania testów, co pozwala rozwijać je równolegle z powstającym kodem. Dodatkową zaletą jest to, że praktykując pisanie unit testów ciągle rozwijamy swoje umiejętności w tej dziedzinie.

Wysokie pokrycie kodu testami

Jest to częste wymaganie w projektach komercyjnych. Stosowanie TDD bardzo ułatwia sprawę, bo testy przygotowane są jeszcze przed rozpoczęciem implementacji.

Podsumowanie

Uffff, w dużym uproszczeniu omówiliśmy dzisiaj całe podejście do tworzenia oprogramowania w myśl TDD. Oczywiście wiedza tutaj przedstawiona to jedynie czubek góry lodowej i jak zawsze gorąco zachęcam Cię do samodzielnego jej zbadania 🙂 Stosowanie tego podejścia może początkowo wydawać Ci się niepotrzebne i nadmiarowe, ale uwierz, że w miarę nabierania wprawy
zauważysz korzyści, o których pisałem. Najważniejsza tutaj będzie jednak praktyka. Tak więc złap za klawiaturę… wróć. Najpierw weź kartkę i zaprojektuj swoją aplikację, następnie złap za klawiaturę i spróbuj zrealizować go zgodnie z zasadami TDD. Gwarantuję Ci, że docenisz to podejście.

Ten artykuł jest też ostatnim (na ten moment) z serii o testach. Mam nadzieję, że wiedza, która się z Tobą podzieliłem pomogła Ci poprawić swoje umiejętności testowania aplikacji. W przyszłości planuję jeszcze rozwinąć temat testowania, jednak aktualnie seria jest zakończona. Przypominam, że całość możesz znaleźć pod tym linkiem. W trakcie serii umieściłem trochę kodu w moim repozytorium na Bitbuckecie, więc możesz w każdej chwili na niego zerknąć. Jeśli ten post lub cała seria była dla Ciebie przydatna to będę MEGA wdzięczny za podzielenie się nią w mediach społecznościowych, przyciski do tego znajdziesz poniżej 🙂

Please follow and like us:

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.