TECH TALK 2 TEST DRIVEN DEVELOPMENT

TDD - Test Driven Development

TDD - co to jest?

Technika wytwarzania oprogramowania, gdzie przed napisaniem kodu produkcyjnego, tworzymy testy.

Dlaczego warto zacząć od testów?

FIRST properties: T (timely) - o czasie, a najlepiej przed kodem.

1. Nuda: mój Kod już jest i działa (sprawdziłęm ręcznie), nie chce mi się pisać testów.

2. Wybory projektowe: pisanie testów sprawia, że nowa klasa/funkcja z definicji nadaje się do testowania (i nie jest to trudne). Poza tym powiązania/zależności między klasami są "luźne", tj. można w łatwy sposób zmienić jedną z nich bez konieczności zmiany pozostałych.

3. Jest trudniej coś przeoczyć, gdy zapisujemy kryteria w postaci testu przed napisaniem kodu produkcyjnego. Po napisaniu kodu najczęściej testy, które tworzymy, potwierdzają jedynie nasze założenia zamiast je weryfikować.

4. Sprzyja powstawaniu "ładnych" interfejsów pomiędzy komponentami (zaczynając od testów, zakładamy jakieś wejścia/wyjścia, sposoby interakcji między klasami, itp.)

5. Szybkość w znajdowaniu/rozwiązywaniu problemów: nie potrzeba całego programu, żeby znaleźć i naprawić błąd w jakiejś jego części

6. Dokumentacja, która zmienia się na bieżąco i jest zawsze aktualna

7. Najmniejszy koszt zmiany - na poziomie testów jednostkowych

8. TDD skutkuje obszernymi garniturami testów jednostkowych, które świetnie zabezpieczają nas przed wprowadzeniem błędów podczas refaktoringu. Dodaje to odwagi, by naprawiać/ulepszać kod, który (niezadbany) zaczyna "gnić" (stawać się nieczytelny, niespójny, niezrozumiały, nad wyraz skomplikowany, itp.)

WIĘCEJ: 9 zalet TDD

WIĘCEJ: Dlaczego TDD?

3 PRAWA TDD

1. Nie wolno Ci napisać żadnego kodu produkcyjnego dopóki nie napiszesz nieprzechdzącego testu jednostkowego.
2. Nie wolno Ci napisać więcej testów jednostkowych niż potrzeba by przestały przechodzić (niekompilowanie się = nieprzechodzenie).
3. Nie wolno Ci napisać więcej kodu produkcyjnego niż potrzeba by zmienić nieprzechodzący testy jednostkowy w przechodzący.

3 - laws of TDD (po angielsku brzmi to dużo lepiej):

1. You are not allowed to write any production code until you write a failing unit test.
2. You cannot write more of a unit test than it is sufficient to fail (not compiling is failing).
3. You are not allowed to write more production code than its sufficient to make a failing unit test pass.

Cykl TDD: Red -> Green -> Refactor

1. Zacznij od napisania nieprzechodzącego testu.
2. Napisz kod produkcyjny, który sprawi, że test zacznie przechodzić.
3. Zrefaktoryzuj kod produkcyjny i testy (w miarę potrzeb), przejdź do 1.

Jak nauczyć się TDD?

TDD wymaga praktyki. Jedną z prostszych form wdrożenia się w ten styl pracy jest wykonywania tzw. "kata". Są to proste zadania programistyczne, których struktura ułatwia rozwiązywanie ich w sposób iteracyjny (implmentacja krok po kroku kolejnych faz/części problemu, aż do końcowego rozwiązaia).

WIĘCEJ: KATA - przykłady

TDD - pułapki, jak nie być mądrzejszym niż się nam wydaje ;)

WIĘCEJ: TDD - "smrodki"

WIECEJ: Kolejność komplikowania rozwiązania (tłumaczenie baaaaardzo autorskie:D)