TDD okiem Frontend Developera
Większość programistów słyszała o Test-Driven Development, jednak wielu nadal nie praktykuje tej techniki pisania kodu w swojej codziennej pracy. Wielu developerów wychodzi z założenia, że jest to technika trudniejsza od standardowego podejścia. TDD wymaga od nas zmiany swoich nawyków, ale jednocześnie przynosi wiele zalet.
Zalety TDD
Pisząc testy do gotowego kodu albo, co gorsza, nie pisząc testów (!), tracimy wiele korzyści. Porównując TDD ze zwykłym pisaniem testów, można zauważyć:
Brak wymówek do pominięcia testów
Po ukończeniu komponentu lub całego widoku, początkowe zadowolenie z wykonanej pracy może ustąpić miejsca myśli: “Muszę dopisać jeszcze kilkadziesiąt testów, to przecież sama nudna robota!”.
Od tego miejsca jest już bardzo blisko do obniżenia jakości testów lub ich pominięcia z powodu braku motywacji. Dzięki pracy w cyklu test → implementacja → refaktoryzacja unikamy tego problemu, ponieważ nie kumulujemy “nudnych” testów na koniec, lecz przeplatamy je z “ciekawym” pisaniem funkcjonalności.
Zawsze “testowalne” funkcjonalności
Pisząc test przed napisaniem pierwszej linijki kodu, nie ma możliwości, aby pisany przez nas kod był trudny do przetestowania. Dzięki zastosowaniu TDD nigdy nie spotka nas sytuacja, w której musimy zmodyfikować kod tak, aby móc napisać do niego testy. Pozwala to na zaoszczędzenie czasu i niepotrzebnej refaktoryzacji.
Zwięźlejszy kod
Kod wykraczający poza określone wymagania nie jest wartością dla klienta. Jest to natomiast dodatkowy nakład czasu i pracy na przyszłość związany z utrzymaniem dodatkowej logiki. TDD skutecznie powstrzymuje nas przed pisaniem nadmiarowego kodu. Etap implementacji prowadzimy wyłącznie do zazielenienia testów, co zapobiega pisaniu “na zapas” oraz “bo kiedyś się przyda”.
Łatwość utrzymania wysokiej jakości
W każdej chwili możemy bezproblemowo przeprowadzić refaktoryzację wcześniej napisanego kodu. Przechodzące testy to gwarancja tego, że wprowadzone przez nas zmiany są bezpieczne. Znika więc strach przed tym, że podczas udoskonalania implementacji możemy coś niechcąco zepsuć. Dzięki temu nasz kod ma o wiele mniejszą szansę na uzyskanie w przyszłości niesławnego miana legacy.
TDD na frontendzie — praktyczne porady
Podczas pracy z TDD na frontendzie wyciągnąłem kilka ciekawych praktyk. Dzięki ich zastosowaniu moja praca z TDD stała się przyjemniejsza i płynniejsza.
Zacznij od najprostszego testu
Swoją pracę nad nowym komponentem zaczynam od stworzenia pliku z testem, który ma potwierdzić, że wyświetlił się pusty div. Brzmi to banalnie, ale jest to świetna rozgrzewka. Taki test daje nam chwilę na odpowiednie nazwanie komponentu oraz weryfikuje czy nie popełniliśmy jakiegoś przypadkowego błędu podczas tworzenia całej otoczki pod nowy kawałek kodu.
Zostaw stylowanie na sam koniec
Osobiście wyróżniam trzy składowe komponentu:
- strukturę — ułożenie elementów oraz ich warunkowe wyświetlanie
- interakcję z użytkownikiem — wszystkie akcje, które może wywołać użytkownik
- wygląd — style nałożone na strukturę
Używając TDD, nigdy nie sprawdzam jak wygląda komponent, dopóki nie pokryję testami struktury i interakcji z użytkownikiem. W początkowej fazie uruchomione mam wyłącznie narzędzie do testowania w trybie watch. Dopiero po tym etapie dopisuję story i zaczynam stylowanie z pomocą Storybooka.
Takim sposobem na etapie dodawania styli są już widoczne wszystkie elementy wraz z przypisaną do nich interakcją. Ułatwia to dalszą pracę oraz sprawdzanie, czy wszystkie części komponentu zachowują się zgodnie z makietą lub zapisanymi założeniami.
Oczywiście podczas stylowania może zmienić się struktura komponentu. Doświadczenie pokazało mi jednak, że ewentualne poprawienie testów jest o wiele szybsze i prostsze niż ciągłe dostosowywanie stylowania do rozrastającej się stopniowo struktury komponentu.
Pierwsza wersja implementacji nie musi być idealna
Na samym początku ważne jest to, aby test stał się zielony. Kod nie musi być wtedy piękny. Daje nam to szybką informację zwrotną o problemie, który rozwiązujemy w ramach aktualnego cyklu test → implementacja → refaktoryzacja.
Po wykonaniu commita z taką implementacją pamiętajmy o jej natychmiastowej refaktoryzacji. O wiele łatwiej jest poprawiać małe elementy niż zmieniać cały komponenet/widok na końcowym etapie prac. Jeśli każdy mały kawałek kodu jest zrobiony porządnie, to o wiele szybciej możemy dodać do niego kolejne zmiany.
Podsumowanie
Stosowanie TDD potrafi wnieść wiele korzyści do projektu oraz nie jest tak skomplikowane, na jakie się wydaje. Pamiętajmy jednak, że wykorzystanie tej techniki wiąże się ze zmianą swoich nawyków pracy, dlatego polecam wprowadzanie TDD stopniowo.
Zachęcam do zadawania pytań i dzielenia się swoimi własnymi doświadczeniami w komentarzach. Dla osób głodnych wiedzy zostawiam dwa artykuły przybliżające TDD: