Przedstawiamy Jmock

Próbując wprowadzić JMock, tworzymy test TestAccountService przy użyciu JMock, jak na listingu 5.

W listingu wykonujemy następujące czynności:

1. Jak zawsze, zaczynamy od zaimportowania wszystkich potrzebnych nam obiektów (1). Jak widać, w przeciwieństwie do EasyMock, platforma JMock nie opiera się na żadnych statycznych funkcjach importu.
2. JUnit5 zapewnia programistyczny sposób rejestrowania rozszerzeń. W przypadku JMock odbywa się to poprzez adnotację nieprywatnego pola instancji JUnit5Mockery za pomocą @RegisterExtension. Obiekt kontekstu służy nam do tworzenia mocków i definiowania oczekiwań (2).
3. W (3) deklarujemy AccountManagera, którego chcemy mockować. Podobnie jak EasyMock, podstawowa struktura JMock tylko symuluje interfejsy.
4. W metodzie @BeforeEach, która jest wykonywana przed każdą z metod @Test, programowo tworzymy mock'a za pomocą obiektu kontekstu (4).
5. Podobnie jak w przypadku każdej z poprzednich aukcji, deklarujemy dwa konta, za pomocą których będziemy przesyłać pieniądze między (5).
6. W (6) zaczynamy deklarować oczekiwania, konstruując nowy obiekt Expectations.
7. W (7) deklarujemy pierwsze oczekiwanie, każde z nich ma postać:

Wszystkie klauzule są opcjonalne, z wyjątkiem pogrubionych - invocation-count i mock-object. Musimy określić, ile wywołań nastąpi i na którym obiekcie. Następnie, w przypadku gdy metoda zwraca obiekt, możemy zadeklarować obiekt zwracany za pomocą konstrukcji will (returnValue ()).

Idąc tą drogą:

W (8) rozpoczynamy transfer z jednego konta na drugie, a następnie potwierdzamy oczekiwane rezultaty (9). To takie proste!

Ale czekaj, co się stało z weryfikacją liczby wywołań? We wszystkich poprzednich przykładach musieliśmy sprawdzić, czy wywołania oczekiwań miały miejsce określoną liczbę razy. Dzięki JMock nie musisz tego robić - zajmuje się tym rozszerzenie JMock, a jeśli którekolwiek z oczekiwanych wywołań nie zostanie wykonane, test zakończy się niepowodzeniem.

Fragment kodu z listing 6 otwiera połączenie HTTP z podanym adresem URL i odczytuje zawartość pod tym adresem URL. Załóżmy, że ten kod jest jedną z metod większej aplikacji, którą chcesz przetestować jednostkowo.

 W tym listingu:

• Otwieramy połączenie HTTP (1)
• Czytamy wszystkie otrzymane treści (2)
• Jeśli wystąpi błąd, zwracamy null (3)

Chcemy przetestować metodę getContent WebClient. W tym celu musimy mockować wszystkie zależności od tej metody. W tym przykładzie mamy dwie zależności - jedna to ConnectionFactory, a druga to InputStream. Podążając za wzorcem z EasyMock, spróbujmy pokazać test WebClient, tym razem używając JMock.

W listing 7 wykonujemy następujące czynności:

• Przypadek testowy rozpoczynamy od zarejestrowania rozszerzenia JMock. Kontekst pola instancji nieprywatnej JUnit5Mockery jest opatrzony adnotacją @RegisterExtension (1).
• Aby nakazać JMockowi tworzenie obiektów mockowych nie tylko dla interfejsów, ale także dla klas, musimy ustawić właściwość imposteriser kontekstu (2). Teraz możemy kontynuować tworzenie mocków w normalny sposób.
• W (3) deklarujemy i programowo inicjalizujemy dwa obiekty, z których chcemy tworzyć mocki.
• W (4) rozpoczynamy deklarację oczekiwań. Zwróć uwagę na piękny sposób, w jaki deklarujemy kolejne wykonanie metody read () strumienia (5), a także zwracane wartości.
• W (6) wywołujemy testowaną metodę, aw (7) potwierdzamy oczekiwany wynik.
• Aby uzyskać pełny obraz tego, jak korzystać z biblioteki JMock, udostępniamy również inną metodę @Test, która testuje naszego WebClienta w wyjątkowych warunkach. W (8) deklarujemy oczekiwanie na wyzwolenie metody close (), aw (9) poinstruujemy JMock, aby zgłosił IOException, gdy wystąpi ten trigger.

Wnioski

W tym artykule przedstawiono kroki potrzebne do przetestowania aplikacji Java za pomocą JUnit 5 i JMock. Pokazaliśmy, jak przetestować funkcjonalność AccountService, mockując AccountManager i WebClient przez mockowanie ConnectionFactory i InputStream.

Jak widać, biblioteka JMock jest równie łatwa w użyciu jak biblioteka EasyMock, ale zapewnia lepszą integrację z JUnit 5 - możemy programowo zarejestrować pole kontekstu Mockery. Nadal musimy przyjrzeć się trzeciemu z proponowanych ram: Mockito. Zobaczymy, że ten jest bliżej paradygmatu JUnit 5!

Interesujesz się JUnit? Sprawdź nasze szkolenia

Catalin Tudose
Java and Web Technologies Expert