czym jest Test-Driven Development (TDD)?

large__8282043567Test-Driven Development to proces, który polega na powtarzaniu bardzo krótkiego cyklu rozwoju. Jest on oparty na testowej koncepcji Extreme Programming (XP), która zachęca do prostego projektowania z wysokim poziomem pewności.

procedura wykonywania TDD jest następująca:

  1. napisz test
  2. Uruchom wszystkie testy
  3. napisz kod implementacyjny
  4. Uruchom wszystkie testy
  5. Refactor

procedura ta jest często nazywana Red-Green-Refactor.

pisząc testy jesteśmy w stanie czerwonym. Ponieważ test jest napisany przed rzeczywistą implementacją, powinien się nie powieść. Jeśli nie, test jest zły. Opisuje coś, co już istnieje lub zostało napisane nieprawidłowo. Bycie na zielono podczas pisania testów jest oznaką fałszywie pozytywnego wyniku. Takie testy powinny zostać usunięte lub zrefakturowane.

nastepny jest zielony stan. Po zakończeniu realizacji ostatniego testu wszystkie testy powinny przejść. Jeśli nie, implementacja jest błędna i powinna zostać poprawiona.

nie chodzi o to, aby implementacja była ostateczna, ale o dostarczenie wystarczającej ilości kodu do przejścia testów. Gdy wszystko będzie zielone, możemy przystąpić do refaktoryzacji istniejącego kodu. Oznacza to, że uczynimy kod bardziej optymalnym bez wprowadzania nowych funkcji. Podczas refaktoryzacji wszystkie testy powinny być zdane przez cały czas. Jeśli jeden z nich zawiedzie, refactor złamał istniejącą funkcjonalność. Refaktoryzacja nie powinna obejmować nowych badań.

szybkość jest kluczem

large_5836417589
mam tendencję do postrzegania TDD jako gry w ping ponga (lub tenisa stołowego). Gra jest bardzo szybka. To samo dotyczy TDD. Zwykle nie spędzam więcej niż minuty po obu stronach stołu (test i wdrożenie). Napisz krótki test i uruchom go (ping), napisz implementację i uruchom wszystkie testy (pong), napisz kolejny test (ping), napisz implementację tego testu (pong), refactor i potwierdź, że wszystkie testy przechodzą (wynik), powtórz. Ping, pong, Ping, pong, Ping, Pong, score, serve again. Nie próbuj tworzyć idealnego kodu. Zamiast tego, spróbuj utrzymać piłkę toczenia, aż uważasz, że nadszedł czas, aby zdobyć (refactor).

tu nie chodzi o testowanie

T w TDD jest często źle rozumiane. TDD to sposób, w jaki podchodzimy do projektowania. Jest to sposób na zmuszenie nas do zastanowienia się nad implementacją przed napisaniem kodu. Jest to sposób na lepszą strukturę kodu. Nie oznacza to jednak, że testy wynikające z użycia TDD są bezużyteczne. Daleko mi do tego. Są one bardzo przydatne i pozwalają nam rozwijać się z dużą prędkością, nie obawiając się, że coś zostanie złamane. Jest to szczególnie prawdziwe, gdy odbywa się refaktoryzacja. Możliwość reorganizacji kodu, mając pewność, że żadna funkcjonalność nie jest zepsuta, jest ogromnym wzrostem jakości kodu.

głównym celem TDD jest projektowanie kodu z testami jako bardzo użytecznym produktem ubocznym.

wyśmiewanie

aby testy działały szybko, zapewniając tym samym stałą informację zwrotną, kod musi być zorganizowany w taki sposób, aby metody, funkcje i klasy mogły być łatwo wyśmiewane i stubowane. Szybkość wykonania zostanie poważnie naruszona, na przykład nasze testy muszą komunikować się z bazą danych. Drwiąc z zewnętrznych zależności jesteśmy w stanie drastycznie zwiększyć tę prędkość. Wykonanie całego zestawu testów jednostkowych powinno być mierzone w minutach, jeśli nie sekundach. Co ważniejsze niż szybkość, zaprojektowanie kodu w taki sposób, aby można go było łatwo wyśmiać i stubbować, zmusza nas do lepszej struktury tego kodu poprzez zastosowanie rozdziału obaw. Z mockami lub bez, Kod powinien być napisany w taki sposób, że możemy na przykład łatwo zastąpić jedną bazę danych inną. Ten „inny”może być np. wyśmiewany lub przechowywany w pamięci.

przykład szydzenia w Scali można znaleźć w artykule Scala Test-Driven Development (TDD): Unit Testing File Operations with specs2 and Mockito. Jeśli wybranym językiem programowania nie jest Scala, artykuł może być nadal bardzo przydatny, aby zobaczyć wzorzec, który można zastosować do dowolnego języka.

Watchers

bardzo przydatnym narzędziem podczas pracy w modzie TDD są watchers. Są to frameworki lub narzędzia, które są wykonywane przed rozpoczęciem pracy i obserwują każdą zmianę w kodzie. Po wykryciu takiej zmiany uruchamiane są wszystkie testy. W przypadku JavaScript pozwalają na to prawie wszystkie systemy budowania i biegacze zadań. Gulp (mój ulubiony) i Grunt to dwa z wielu przykładów. Scala posiada m.in. rewolwer sbt. Większość innych języków programowania ma podobne narzędzia, które rekompilują (w razie potrzeby) i uruchamiają wszystkie (lub dotknięte) testy, gdy zmienia się kod. Zawsze kończę mając mój ekran podzielony na dwa okna. Jeden z kodem, nad którym pracuję, a drugi z wynikami testów, które są wykonywane w sposób ciągły. Wszystko, co muszę zrobić, to zwrócić uwagę, że wyjście tych obserwatorów odpowiada fazie, w której jestem (czerwony lub zielony).

dokumentacja

kolejnym bardzo użytecznym efektem ubocznym TDD (i ogólnie dobrze zorganizowanych testów) jest dokumentacja. W większości przypadków o wiele łatwiej jest dowiedzieć się, co robi kod, patrząc na testy, niż na samą implementację. Dodatkową korzyścią, której nie mogą zapewnić inne rodzaje dokumentacji, jest to, że testy nigdy nie są przestarzałe. Jeśli istnieją jakiekolwiek rozbieżności między testami a kodem implementacyjnym, testy kończą się niepowodzeniem. Nieudane testy oznaczają niedokładną dokumentację.

testy jako dokumentacja artykuł zawiera nieco głębsze uzasadnienie użycia testów zamiast tradycyjnej dokumentacji.

podsumowanie

z mojego doświadczenia wynika, że TDD jest prawdopodobnie najważniejszym narzędziem, jakie mamy w naszym zestawie narzędzi. Potrzeba dużo czasu i cierpliwości, aby stać się biegłym w TDD, ale po opanowaniu tej sztuki wydajność i jakość drastycznie rosną. Najlepszym sposobem na naukę i ćwiczenie TDD jest połączenie z programowaniem parowym. Podobnie jak w grze W ping ponga, która wymaga dwóch uczestników, TDD może być w parach, gdzie jeden koder pisze testy, a drugi pisze implementację tych testów. Role mogą się zmieniać po każdym teście (jak to często robi się w kodowaniu Dojo).

spróbuj i nie poddawaj się w obliczu przeszkód, ponieważ będzie ich wiele.

Test Driven Development (TDD): najlepsze praktyki z wykorzystaniem przykładów Javy to dobry punkt wyjścia. Mimo, że używa przykładów Java, te same, jeśli nie wszystkie, praktyki mogą być stosowane do dowolnego języka programowania. Dla przykładu w Javie (tak jak w poprzednim przypadku, można go łatwo zastosować do innych języków) proszę spojrzeć na przykładowy artykuł TDD solucja.

kolejnym świetnym sposobem na doskonalenie umiejętności TDD są code katas (jest ich wiele na tej stronie).

jakie masz doświadczenia z TDD? Jest tyle odmian, ile zespołów ćwiczących to i chciałbym usłyszeć o twoich doświadczeniach.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.