Spis treści
Istnieje popularna konwencja definiująca, jak testy jednostkowe powinny być ustrukturyzowane. Zakłada ona, iż:
- Na początku testu przygotowujemy dane, które posłużą jako dane wejściowe, na których testowana metoda będzie działać. Ta część testu nazywa się given.
- Następnie, wywołujemy testowaną metodę na danych przygotowanych w punkcie pierwszym. Ta część testu to when.
- Na końcu testu sprawdzamy, czy wynik zwrócony przez metodę wywołaną w punkcie drugim jest zgodne z naszymi oczekiwaniami. Ta ostatnia część testu to then.
Konstruując test w ten sposób dostajemy logiczną całość:
- dla takich a takich danych (given),
- gdy wykonam taką metodę (when),
- powinienem otrzymać taki a taki rezultat (then).
Spójrzmy na przykład jednego z testów z poprzedniego programu napisanego w taki właśnie sposób. Dla porównania dodana została także poprzednia wersja tego testu:
public static void doKwadratu_wartoscDodatnia_wartoscPodniesionaDoKwadratu() { int wynik = doKwadratu(20); assertEquals(400, wynik); } public static void doKwadratu_wartoscDodatnia_wartoscPodniesionaDoKwadratu2() { // given int liczba = 20; // when int wynik = doKwadratu(liczba); // then assertEquals(400, wynik); }
Druga metoda stosuje opisaną powyżej konwencję – komentarzami oddzieliliśmy od siebie poszczególne części testu. Ze względu na czytelność, testy są często pisane w ten właśnie sposób.
Nasz test jest prosty i w zasadzie nie ma potrzeby na tworzenie zmiennej liczba tylko po to, by przypisać do niej wartość i użyć jej jako argument metody doKwadratu. Celem było ukazanie przykładu konwencji given .. when .. then. Mniej skomplikowane testy możemy zapisywać zwięźlej, nie korzystając z konwencji given .. when .. then. Wszystko zależy od tego, którą wersję z testów uważamy za czytelniejszą i łatwiejszą do zrozumienia przez innych programistów.