Test-driven development i nie tylko

Jedną z najbardziej charakterystycznych rzeczy w metodologii Test-driven development (TDD) jest cykl red-green-refactor.

Technika ta wymaga od developera ogromnej dyscypliny i cierpliwosci. Jednakże lista korzyści wynikająca z takiego podejścia jest bardzo długa:

• kryteria akceptacji - przed rozpoczęciem pisania kodu aplikacji zaczynamy pisać testy jednostkowe jako znacznik implementacji konkretnych wymagań. Bez tej listy nie jesteśmy w stanie rozpocząć zadania
• koncentracja - ponieważ w jednym momencie pracujemy nad jednym testem nasza cała uwaga skupia się wyłącznie na ułamku funkcjonalności
• publiczne API - pisanie testu jednostkowego przed pojawieniem się kodu testowanego wymusza na nas precyzyjne i lepsze określenie interfejsów publicznych naszej funkcjonalności
• czystszy kod - ponieważ w TDD pracujemy jedynie na publicznych interfejsach komponentów mamy większą świadomość tego co należy a czego nie należy w nich publikować (aby m.in. uniknąć konieczności wspierania publicznej funkcjonalności w przyszłości)
• zależności - pisząc testy jednostkowe przed pisaniem kodu wymusza na nas dokładną analizę (i mockowanie) zależności naszego komponentu co sprawia, że na wskutek analizy możemy ograniczyć ich ilość
• bezpieczniejszy refaktoring - posiadając bazę testów zabezpieczających wymagania naszego produktu jesteśmy w stanie przeprowadzić liczne sesje refaktoringu upewniając się, że na ich końcu funkcjonalność systemu nie została utracona/zepsuta
• mniejsza liczba błedów - lepsze pokrycie testami oraz dokładniej przemyślany system już na poziomie komponentów powoduje generowanie mniejszej ilości błędów przez developera
• dokumentacja - testy tworzone w ramach TDD są odzwierciedleniem wymagań stawianych przed produktem, a więc są żyjącą jego dokumentacją

Given-When-Then

Given-When-Then (GWT) jest techniką pozwalający w prosty sposób nie tylko uporządkować kod naszych testów i poprawić ich czytelność ale także zidentyfikować co naprawdę jest testowane. Pojedynczy test pisany w tym schemacie wygląda następująco:

  it('should return car engine name', function() {
    // Given
    var car = new Car('V8');

    // When
    var message = car.drive(80);

    // Then
    expect(message).toBe('Car with V8 engine drives at 80 km/h.');
  });

Status pending

Przepisując wymagania na testy jednostkowe często znajdujemy się w sytuacji, gdzie wymagania są wszystkie znane lecz implementacja dla nich jeszcze nie istnieje (w TDD koncentrujemy się na jednym teście w jednym momencie). To nie musi oznaczać, że spis potrzebnych testów nie może powstać od razu.

Test oznaczony jako pending to taki, który ma pojawiać się na liście testów raportu lecz jego wynik ma być tymczasowo ignorowany (brak implementacji nie będzie powodować negatywnego wyniku puszczenia wszystkich testów).

  xdescribe('lastSpeed property', function () {
    xit('should return 0 when car have never driven', function () {
    });

    xit('should return car last speed', function () {
    });
  });

Przykład 4.1.