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.

maj 26, 2021 159

JUnit5ExceptionTester class.JPG


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.

JUnit4RuleTester class.JPG


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).

JUnit5TempDirTester class.JPG


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.

CustomRule class.JPG


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

Udostępnij


Masz jeszcze jakieś pytania?
Skontaktuj się z nami
Thank you.
Your request has been received.