Wzorzec Given-When-Then w testach jednostkowych

Zaktualizowaliśmy ten tekst dla Ciebie!
Data aktualizacji: 21.08.2024
Autor aktualizacji: Marcin Łącki

Czym jest wzorzec Given-When-Then?

Wywodzi się on z podejścia BDD(Behavior-Driven Development). Idą tego podejścia jest rozwój oprogramowania oparty na zachowaniach. Użytkownik, używając języka naturalnego opisuje zachowanie aplikacji używając do tego prostych zdań. W znaczący sposób ułatwia to czytelność i zrozumienie zachowania aplikacji.

W tym podejściu wyróżniamy trzy główne kroki przedstawione na grafice poniżej:

Given – w tym kroku tworzymy założenia początkowe, które są niezbędne do wykonania testów. Przykładem może być założenie, że użytkownik jest już zalogowany do systemu

When – w kroku When określamy jaką akcję chcemy wykonać

Then – za pomocą tego kroku dokonujemy sprawdzenia, czy aplikacja zachowała się dokładnie z oczekiwaniami (asercja)

Wzorzec Given-When-Then w testach jednostkowych

Podejście BDD jest bardzo popularnym sposobem pisania kryteriów akceptacji dla historyjek użytkowników. Czy może być również przydatne do pisania testów jednostkowych? Oczywiście, że tak!
Główna koncepcja wzorca Given-When-Then polega na przedstawieniu przepływu procesu w sposób czytelniejszy dla tego jak człowiek wyobraża sobie problem. Dobrze napisany test jednostkowy opisuje pewną, najczęściej bardzo małą, część zachowania systemu. Dzięki takiemu podejściu możemy traktować go w ten sam sposób, jak na przykład test akceptacyjny. Dzięki swojej prostocie testy jednostkowe wykonują się szybciej i zespół w krótkim czasie otrzymuje informacje zwrotne o tym czy w procesie produkcji nie zostały wprowadzone błędy.

Spójrz na przykład w kodzie:

@Test
public void shouldDeliverCargoToDestination() {
    // given
    Driver driver = new Driver("Teddy");
    Cargo cargo = new Cargo();
    Position destinationPosition = new Position("52.229676", "21.012228");
    Truck truck = new Truck();
    truck.setDriver(driver);
    truck.load(cargo);
    truck.setDestination(destinationPosition);

    // when
    truck.driveToDestination();

    // then
    assertEquals(destinationPosition, truck.getCurrentPosition());
}

Test jednostkowy został podzielony na trzy części: Given, When, Then. Dla poprawy czytelności części zostały oznaczone komentarzami. W sekcji „Given” powinniśmy umieścić definicje obiektów, definicje mocków, i wszystkie początkowe założenia, które są niezbędne do wykonania testu. W sekcji „When” umieszczamy akcję/zachowanie, które chcemy przetestować, np dokonanie obliczen. Sekcja „Then” jest przeznaczona do weryfikacji. Tutaj umieszczamy nasze asercje.

Mimo założen Given-When-Then nie jesteśmy zobligowani to używania każdej z tych części. Oczywiście poprawia to w znaczący sposób czytelność jednak zdarza się, że kroki przygotowawcze zamiast w sekcji Given są zdefiniowane w ramac metody setUp()

Dzięki podejściu opartemu na zachowaniach powyższy kod możemy opisać zdaniami

Scenariusz: „Ciężarówka powinna dostarczyć ładunek do wyznaczonego celu”

Given :
-Gotowa do jazdy ciężarówka z kierowcą o imieniu Teddy
– Wymagany towar został załadowany na ciężarówkę
– Została wyznaczona trasa w systemie nawigacyjnym

When:
– kierowca Teddy jedzie to wcześniej wyznaczoną trasą z zadanym miejscem dostarczenia ładunku

Then:
– towar został dostarczony do miejsca docelowego

Korzyści z podejścia behawioralnego:

• Lepsza czytelność testu: wszystkie testy mają tę samą strukturę, więc możemy szybciej zrozumieć ich sens.
• Uporządkowana struktura: wszystkie testy są podzielone na trzy części. Dzięki temu nawet jeśli test jest skomplikowany, w łatwy sposób możemy znaleźć początkowe założenia lub asercje.
• Globalny wzorzec: jeśli wszyscy nasi współpracownicy używają tego wzorca nie będziemy mieć problemu ze zrozumieniem testów stworzonych przez innych.
• Łatwiejsza konserwacja: testy stworzone w ten sposób będą łatwiejsze w utrzymaniu.
• Sposób myślenia: testy są tworzone w sposób w jaki myślą ludzie.

Dzięki wzorcowi Given-When-Then w kodzie zachowany jest porządek i czytelność. Jest to o tyle kluczowe, że dobrze napisane testy jednostkowe są najlepszą dokumentacją kodu