Test Driven Development

Test driven development należy do technik zwinnego wytwarzania oprogramowania, a nie do jego testowania, co można mylnie pomyśleć patrząc na nazwę tej techniki bez zastanowienia.
TDD polega na tworzeniu nowego lub rozwoju już istniejącego kodu.
Technika ta polega na napisaniu testu przed napisaniem kodu, który będzie ten test przechodził. Pozwala to na wytwarzanie kodu zgodnego z dokumentacją, przemyślanego ponieważ z góry trzeba przewidzieć i zaprojektować zależności, które będą potrzebne w projekcie. Stosując TDD unikamy tworzenia niepotrzebnego kodu oraz pisany kod jest prostszy ponieważ podczas jego tworzenia skupiamy się jedynie na napisaniu kodu, który ma przejść stworzony przez nas zgodny z wymaganiami dokumentacji test, a nie piszemy czegoś co kiedyś w przyszłości może być przydatne, a często może się okazać nie tylko zbędne co nawet szkodliwe.

Kod w technice Test Driven Development wytwarzany jest w cyklach, a każdy cykl składa się z trzech elementów:

  1. Red – pierwszy etap cyklu polega na napisaniu testów, których nasz kod nie powinien przejść, ponieważ testowana funkcjonalność nie została jeszcze zaimplementowana.
  2. Green – drugi etap polega na tworzeniu kodu zgodnego z dokumentacją oraz przechodzącego przez wszystkie napisane testy. Kod ten nie musi być perfekcyjny, ma jednak za zadanie spełniać wymagania testów
  3. Refactor – ostatnim etapem jest refaktoryzacja kodu czyli poprawa jego jakości, bez zmian w jego funkcjonalności oraz ponowne sprawdzenie czy napisany kod nadal przechodzi przez wszystkie testy.

Skoro wiemy już czym jest i jak wygląda jego stosowanie, należy odpowiedzieć na pytanie co zyskujemy dzięki tak pogmatwanej technice tworzenia kodu, a jednocześnie należy zwrócić uwagę jej na wady.

Dzięki zastosowaniu TDD zyskujemy dobry jakościowo kod i możemy szybciej dostrzec ewentualne problemy z zależnościami, dzięki temu że musimy brać je pod uwagę pisząc test na podstawie dokumentacji. Tworzone na bieżąco testy pozwalają na szybkie, a przy okazji bezpieczne dla całości projektu wyłapywanie i naprawianie błędów dzięki natychmiastowej informacji zwrotnej o występujących błędach.

Pierwszą trudnością i zarazem największą związaną z wytwarzaniem kodu z wykorzystaniem TDD jest przestawienie i przekonanie się do tej techniki. Bowiem nie tylko programiści muszą się do niej przekonać ale również managerowie i inne osoby odpowiadające za realizacje projektu. Dla programisty początki są bardzo trudne, ale w dłuższej perspektywie, będzie to bardzo cenna umiejętność, która pozwoli na zwiększenie etyki pracy i pomoże tworzyć lepszy kod, który spełnia wymagania zawarte w dokumentacji, w krótszym czasie. Inną wadą tej techniki jest częste mimowolne pisanie testów pod kod lub kodu pod test tracąc z oczu projekt jako całość, TDD ma służyć do stworzenia oprogramowania, a nie kontroli pracy programisty.

Więcej o Test Driven Development, można przeczytać w bardzo dobrej książce Kenta Becka – Test Driven Development: By Example.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: