Architektura JUnit 5. Część 4

Czwarty artykuł z naszej serii o architekturze JUnit 5. Kontynuujemy nasze dyskusje na temat reguł i modelu rozszerzeń oraz kierujemy naszą uwagę na nowe podejście JUnit 5.

W tym przykładzie JUnit 5 wykonujemy następujące czynności:

1. Inicjujemy wystąpienie Calculator class, którego funkcjonalność testujemy (1').
2. Twierdzimy, że wykonanie dostarczonego pliku wykonywalnego calculator.sqrt (-1) powoduje “wyrzucenie” wyjątku IllegalArgumentException (2').
3. Twierdzimy, że wykonanie dostarczonego pliku wykonywalnego calculator.divide (1, 0) powoduje “wyrzucenie” wyjątku ArithmeticException (3').

Zwracamy uwagę na wyraźną różnicę w klarowności kodu i długości kodu między JUnit 4 i JUnit 5. Efektywny testowy kod JUnit 5 to 13 linii, efektywny kod JUnit 4 to dwadzieścia linii. Nie musimy inicjować żadnej dodatkowej reguły ani nią zarządzać. Każda z metod testujących JUnit 5 zawiera po jednym wierszu.

Kolejną regułą, którą chcielibyśmy migrować, jest TemporaryFolder. Reguła TemporaryFolder umożliwia tworzenie plików i folderów, które powinny zostać usunięte po zakończeniu metody testowej (niezależnie od tego, czy zakończy się ona pomyślnie, czy nie). Reguła JUnit 4 została zastąpiona adnotacją @TempDir w JUnit 5. Listing 4 przedstawia podejście JUnit 4.

W tym przykładzie wykonujemy następujące czynności:

1. Deklarujemy pole TemporaryFolder z adnotacją @Rule i inicjalizujemy je. Adnotację @Rule należy zastosować w polu publicznym lub w metodzie publicznej (1).
2. Używamy pola TemporaryFolder do tworzenia folderu i pliku (2). Można je znaleźć w folderze Temp profilu użytkownika w systemie operacyjnym.
3. Sprawdzamy istnienie folderu tymczasowego i pliku tymczasowego (3).

Teraz skupiamy się na nowym podejściu JUnit 5 (listing 5).

W poprzednim przykładzie JUnit 5 wykonujemy następujące czynności:

1. Deklarujemy pole z adnotacjami @TempDir (1').
2. Sprawdzamy tworzenie tego katalogu tymczasowego przed wykonaniem testu (2').
3. Tworzymy plik w tym katalogu i sprawdzamy jego istnienie (3').

Zaletą w podejściu rozszerzającym JUnit 5 jest to, że nie musimy samodzielnie tworzyć folderu za pomocą konstruktora, ale folder jest tworzony automatycznie, gdy dodamy adnotację do pola @TempDir.

Skupiamy się na zastąpieniu reguły niestandardowej. Własne reguły są szczególnie przydatne, gdy niektóre typy testów wymagają podobnych dodatkowych działań przed i po ich wykonaniu.

W JUnit 4 potrzebowaliśmy naszych dodatkowych własnych akcji do wykonania przed i po wykonanie testu. W konsekwencji możemy stworzyć własne klasy, które implementują interfejs TestRule. Aby to zrobić, należy nadpisać metodę apply (Statement, Description), która zwraca wystąpienie Statement’u. Taki obiekt reprezentuje testy w środowisku wykonawczym JUnit i uruchamia je Statement # assessment (). Obiekt Description opisuje pojedynczy test. Możemy go użyć przez “refleksję” do odczytania informacji o teście.

Aby jasno pokazać, jak zdefiniować własne reguły, przyjrzyjmy się listing 6, gdzie wykonujemy następujące czynności:

1. Deklarujemy naszą klasę CustomRule, która implementuje interfejs TestRule (1).
2. Zachowujemy odniesienia do Statement field i Description field (2) i używamy ich w metodzie Apply, która zwraca CustomStatement (3)

Interesujesz się Javą? Sprawdź nasze szkolenia.

Catalin Tudose
Java and Web Technologies Expert

Originally published at https://www.luxoft-training.pl.