Test Driven Development dla początkujących – cz.1

Postaram się przedstawić w kilku wpisach (w tej chwili szacuję, że to będą 3 lub 4 posty)  podstawowe idee stojące za TDD.  Nie zamierzam pisać tutaj kursu (btw: polecam wpisy na blogu Dariusza Woźniaka), ani kompleksowego opracowania – chodzi mi raczej o przystępne wprowadzenie do koncepcji, w taki sposób aby każdy mógł zacząć pisać najpierw testy a później właściwe funkcjonalności, czerpiąc z tego jak najwięcej korzyści :).

Co to jest Test Driven Development? :
TDD, czyli programowanie sterowane testami to metodyka należąca do praktyk XP, polegająca na pisaniu testów jednostkowych przed pisaniem kodu produkcyjnego. Istotne jest zrozumienie, że głównym celem korzystania z TDD nie jest pokrycie kodu testami, a produkowanie kodu wysokiej jakości w oparciu o te testy.

Po co mi to?
Pisząc testy przed implementacją, najbardziej oczywistą zaletą jest pewność poprawności pisanego kodu (choć jasne jest, że testy nie chronią nas przed błędami w założeniach). Samo to, że kod jest pokryty testami, dobrze rokuje dla zmian w przyszłości ponieważ ktoś kto będzie zmuszony modyfikować nasz kod, ma możliwość zweryfikowania czy nic nie popsuł. Mniej oczywistym faktem jest to, że pisząc najpierw testy mimochodem piszemy lepszy kod – kod który jest testowalny to kod zwykle luźno powiązany, ze zredukowaną liczbą zależności.

Wzorzec Red-Green-Refactor:
Główną osią wokół której obraca się TDD, jest postępowanie mogącę skrótowo być opisane jako Red-Green-Refactor. Dlaczego? Pracując nad kodem postępujemy według instrukcji:

  1. Piszemy test dla nie istniejącej jeszcze funkcjonalności – test się załamie (Red).
  2. Za wszelką cenę(wg. Kent’a Beck’a), nie bacząc na praktyki jeżeli rozwiązanie nie jest oczywiste, sprawiamy by test przeszedł. (Green)
  3. Poprawiamy kod, spłacamy zaciągnięty (chwilkę wcześniej bo w punkcie 2) dług, staramy się by nasz kod był piękny i czytelny 😉 – cały czas dbając o zielony kolor wyniku testu.(Refactor).

I tak, aż do momentu zakończenia pracy :).

Wzorzec Arrange-Act-Assert:
Skoro jest o TDD, to mimochodem warto wspomnieć o wzorcu pisania testów jednostkowych. Już o nim pisałem więc zapraszam tutaj :).

Testy a solucja:
Na zakończenie tego wstępu istotna kwestia dotycząca izolacji testów jednostkowych: Odpowiednim miejscem umiejscowienia testów będzie po prostu nowy projekt. W sytuacji gdy w solucji mamy wiele projektów, dla każdego z nich powinien istnieć odpowiadający mu projekt z testami.


Przedstawiłem tutaj kilka podstawowych kwestii, w kolejnej części weźmiemy na warsztat prosty przykład, gdzie zbudujemy jakąś funkcjonalność od początku do końca podążając ścieżką TDD… 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *