TDD: Test Driven Development

Test  jednostkowy

Test jednostkowy jest w programowaniu metodą testowania tworzonego oprogramowania poprzez wykonywanie testów weryfikujących poprawność działania pojedynczych fragmentów kodu (jednostek) programu – np. metod lub obiektów w programowaniu obiektowym lub procedur w programowaniu proceduralnym. Testowany fragment programu poddawany jest testowi, który wykonuje go i porównuje wynik (np. zwrócone wartości, stan obiektu, wyrzucone wyjątki) z oczekiwanymi wynikami – tak pozytywnymi, jak i negatywnymi (niepowodzenie działania kodu w określonych sytuacjach również może podlegać testowaniu).

Testy jednostkowe powinny cechować:

  • automatyzacja – uruchamianie testów musi być łatwe.
  • kompletność – należy testować wszystko co może zawieść.
  • powtarzalność – wielokrotne wykonanie testu daje te same wyniki.
  • niezależność – od środowiska i innych testów.
  • profesjonalizm – kod testujący jest tak samo ważny jak kod dostarczany klientowi.

Test Driven Development

TDD jest techniką tworzenia oprogramowania sterowanego testami. Istotne jest w tym podejściu, aby przy tworzeniu nowej funkcjonalności, najpierw napisać test, który tę funkcjonalność zweryfikuje zanim ona w ogóle powstanie. Dopiero później dokonujemy implementacji.

TDD krok po kroku

TDD składa się z trzech etapów, które tworzą cykl nazywany RedGreenRefactor. Krótko mówiąc, najpierw piszemy test, następnie implementujemy funkcjonalność, a na końcu refaktoruzyjemy. Na końcu cykl jest powtarzany.

W pierwszym etapie RED piszemy test, który z założenie się nie powiedzie, ponieważ  w tym etapie funkcjonalność jeszcze nie jest zaimplementowana. Testy piszemy do pustych, ale istniejących już klas i metod, a następnie uruchamiamy test i oczekujemy komunikatu o niepowodzeniu.

W kolejnym etapie GREEN piszemy kod, w którym implementujemy brakującą funkcjonalność, aby test się powiódł.

Ostatni etap REFACTOR jest to proces, w którym dokonujemy refaktoryzacji kodu, czyli wprowadzamy zmiany w kodzie w celu poprawy jego jakości nie powodując przy tym zmian w jego funkcjonalności.

Przykład:

Załóżmy, że chcemy dodać funkcjonalność do gry RPG, która pozwoli nam dodawać itemy do naszego ekwipunku.

Zgodnie z opisywanym cyklem zaczynamy od fazy RED.

Oczywiście jeszcze nie mamy klasy Item, więc test nam nie przechodzi.

Aby Nasz test był zielony musimy stworzyć klasę Item.

Test jest zielony, więc teraz możemy przejść dalej. Fazę REFACTOR pomijamy, ponieważ nie mamy na ten moment co poprawiać. Drugi cykl podobnie, jak wcześniej zaczynamy od części RED. Itemy chcemy dodawać do ekwipunku, więc zróbmy to w końcu.

Test nie przechodzi ze względu na brak w Naszym projekcie klasy Inventor, zajmijmy się tym, ponieważ wiemy, że będziemy dodawać itemy do naszego ekwipunku. Dodajmy w klasie od razu listę.

Następnie dodajemy do Naszego testu funkcjonalność, która nas interesuje, dla której ten test tworzymy, tj. dodawanie przedmiotów do ekwipunku.

Test jest czerwony, więc poprawmy to. Oczywiście dodajemy metodą add do naszej klasy Inventory.

Test jest zielony. Nasza metoda jest na ten moment pusta, ale zajmiemy się tym później.

Kolejny cykl zaczynamy od sprawdzenia poprawności dodawania przedmiotów do naszego ekwipunku.

Poprzez dodanie assercji assertThat oraz użycie matchera equalTo jesteśmy wstanie sprawdzić prawdziwość naszego testu. Następnie przechodzimy do fazy GREEN, poprzez dodanie metody getItems do klasy Inventory oraz zapełnienie metody add.

Teraz test przechodzi i wyświetla się na zielono. W przykładzie tym pominięto fazę REFACTOR ze wzlgędu na to że podany przykład jest mały i nie wymaga zmian. Należy pamiętać, że nie zawsze jest tak i faza REFACTOR jest bardzo ważną części tworzenia testów. Pozwala to na zachowanie porządku podobnie, jak w kodzie produkcyjnym.

TDD: Test Driven Development

Dodaj komentarz

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

Przewiń do góry