Menu

Samouczek Mockito: Mockito Framework do mockowania w testach jednostkowych

  • Główny
  • Inny
  • Samouczek Mockito: Mockito Framework do mockowania w testach jednostkowych

mockito tutorial mockito framework

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Kompletny przewodnik po Mockito Framework: praktyczne samouczki Mockito

jaki jest najlepszy darmowy konwerter wideo

Testowanie jednostkowe to prosta, ale skuteczna technika pozwalająca uzyskać dobry poziom zaufania do kodu, który ma zostać wysłany.

Ponadto pozwala uniknąć problemów z regresją z każdym wpisywanym fragmentem kodu.

Przy architekturze mikrousług (a nawet w przypadku prostej struktury obejmującej podstawowe wywołania bazy danych) proste testowanie jednostkowe nie wystarczy. Potrzebujemy mockować zależności i przetestować rzeczywistą logikę testowanej metody.

Przewodnik po Mockito

Lista WSZYSTKICH samouczków Mockito w tej serii:

Samouczek nr 1: Mockito Framework do mockowania w testach jednostkowych (Ten samouczek)
Samouczek nr 2: Tworzenie mocków i szpiegów w Mockito
Samouczek nr 3: Różne typy dopasowań zapewniane przez Mockito
Samouczek nr 4: Mockowanie metod prywatnych, statycznych i pustych za pomocą Mockito
Samouczek nr 5: 12 najpopularniejszych pytań do wywiadu Mockito

************************************************* * *******************

Omówienie samouczków w tej serii Mockito

Instruktaż #Czego się nauczysz
Samouczek nr 1: Mockito Framework do mockowania w testach jednostkowych

Naucz się mockowania z Mockito - wszechstronnym samouczkiem Mockito dla początkujących z przykładami kodu. Dowiedz się Mocking Framework for Mocking in Unit Testing.
Samouczek nr 2: Tworzenie mocków i szpiegów w Mockito

Mocks and Spies to typy podwójnych testów, które są pomocne w pisaniu testów jednostkowych. Oba są wyjaśnione w tym samouczku Mockito Spy z przykładami kodu.
Samouczek nr 3: Różne typy dopasowań zapewniane przez Mockito

Dowiedz się, jak korzystać z różnych typów dopasowań udostępnianych przez Mockito. Dopasowania są jak symbole wieloznaczne, w których zamiast określonego wejścia / wyjścia określasz zakres danych wejściowych. Argument i weryfikacja to dwa typy dopasowań w Mockito, które zostały szczegółowo wyjaśnione tutaj.
Samouczek nr 4: Mockowanie metod prywatnych, statycznych i pustych za pomocą Mockito

Naucz się mockowania metod prywatnych, statycznych i pustych w Mockito z przykładami. Naucz się mockowania metod prywatnych i statycznych za pomocą frameworka testów jednostkowych PowerMockito
Samouczek nr 5: 12 najpopularniejszych pytań do wywiadu Mockito

Mockito Interview Pytania i odpowiedzi z przykładowymi przykładami kodu. Pomoże ci to pomyślnie złamać każdą rozmowę kwalifikacyjną Mockito Mocking Framework.

Zacznijmy od pierwszego samouczka z tej serii !!

Czego się nauczysz:

Mockowanie w testach jednostkowych

Mocks / Stubs to termin, który ludzie często słyszą podczas tworzenia testów jednostkowych.

Więc czym właściwie jest kpina? Mówiąc najprościej, jest to nic innego jak zapewnienie kontrolowanej instancji lub implementacji zależności, od której zależy testowany kod w celu przetestowania jego podstawowej logiki.

Powodem, dla którego wspomniałem o tym jako o kontrolowanej instancji, jest to, że zachowanie zależności można zaprogramować lub kontrolować zgodnie z potrzebami dla testowanej metody lub systemu.

Aby to schematycznie wyjaśnić, weźmy przykład dowolnej aplikacji biznesowej lub e-commerce. Niemal każdy tego typu aplikacja ma przede wszystkim 3 warstwy tj. Interfejs użytkownika, warstwa biznesowa i warstwa dostępu do danych (który komunikuje się z bazowym magazynem danych)

Przykład: zależności UnitTesting

Nawiązując do powyższego diagramu, warstwa biznesowa ma 3 zależności, a mianowicie warstwę dostępu do danych i 2 inne usługi, które są usługą 1 i usługą 2.

Spójrz na to w ten sposób - aplikacja taka jak mapy Google może mieć zależności od pliku

  1. Rzeczywiste magazyny danych, takie jak MySQL lub każda inna baza danych bez SQL, która przechowuje dane map.
  2. Usługa zewnętrzna, taka jak CoordinateService, która dostarcza szerokości i długości geograficzne lokalizacji.
  3. Usługa zewnętrzna, taka jak usługa ruchu drogowego, która zapewnia informacje o ruchu drogowym w czasie rzeczywistym dla danej pary współrzędnych.

Tak więc, jeśli ktoś próbuje zweryfikować podstawową logikę biznesową za pomocą testów jednostkowych, dopóki nie ma działającej implementacji tych zależności, testy nie mogą zostać uruchomione.

Mocks przychodzą na ratunek w takich sytuacjach, w których niezależnie od tego, czy Twoja zależność jest uruchomiona, czy nie, zawsze masz gwarancję, że logika biznesowa będzie działać z zaprogramowaną odpowiedzią na zależność wywoływaną z testowanego kodu.

Rodzaje / kategorie podwójnych testów

Mock to zasadniczo rodzaj „podwójnego testu” - to techniczny żargon. „Test Double” zasadniczo oznacza obiekt, który jest zastępowany przez równoważną rzeczywistą instancję obiektu lub zależność.

Istnieją różne rodzaje testów podwójnych, jak wspomniano poniżej:

# 1) Podróbki:

Fałsz to działająca implementacja podobna do rzeczywistej zależności, z wyjątkiem faktu, że jest lokalna dla testowanego systemu.

Przykład: Zamiast trafiać do prawdziwej produkcyjnej bazy danych, test wykorzystuje prosty zbiór / w pamięci do przechowywania danych.

Rodzaj testu podwójnego - podróbki

# 2) Stuby:

Stuby to wstępnie skonfigurowane odpowiedzi, gdy zależność jest wywoływana z testowanego systemu.

Rodzaj testu podwójnego - zwroty

# 3) Szpiedzy:

Jak sama nazwa wskazuje, jest to w rzeczywistości prawdziwe wywołanie funkcji (zależności) z pewnym mechanizmem obserwującym. Po wysłaniu połączenia można sprawdzić, czy połączenie zostało faktycznie wywołane, czy nie, wraz z parametrami.

Rodzaj testu podwójnego - szpiedzy

# 4) Mocks:

Mocks to specjalne instancje obiektów, dla których można określić zablokowane / wstępnie skonfigurowane odpowiedzi. Fakt, że mock został wywołany, można zweryfikować jako potwierdzenie w teście.

Na przykład:

Istnieje funkcja generatora raportów, która wysyła wiadomość e-mail na podany adres podczas wykonywania.

Ponieważ nie chcemy wysyłać prawdziwych wiadomości e-mail, wielokrotnie podczas testów usługa EmailService jest wyszydzana (a metoda wysyłania wiadomości e-mail jest skonfigurowana tak, aby nic nie robić, gdy jest wywoływana). Na koniec testu możemy po prostu sprawdzić, czy metoda wysyłania wiadomości e-mail usługi e-mail została wywołana za pośrednictwem mockowanego obiektu.

Różne frameworki

Prawie wszystkie języki zapewniają różne rodzaje frameworków. Będziemy pisać przykładowy kod przy użyciu Mockito, które jest open source Mocking framework dla Javy.

Anatomia prostego testu jednostkowego z symulowaną zależnością. Załóżmy, że próbujemy przeprowadzić test jednostkowy aplikacji, która oblicza sumę ocen dla studenta ze wszystkich przedmiotów i zapisuje je w DB.

public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for (int score: scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); }

Teraz, jeśli chcemy napisać test jednostkowy dla metody - calculatorSumAndStore, być może nie mamy prawdziwej implementacji bazy danych do przechowywania sumy. W takim przypadku nigdy nie będziemy mogli przetestować tej funkcji jednostkowo.

Ale mając na miejscu makiety, możemy po prostu przekazać Mock dla usługi bazy danych i zweryfikować resztę logiki

Przykładowy test, jak pokazano poniżej:

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores('student1', 220); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }

Widzieliśmy w powyższym teście, że dostarczyliśmy obiekt mockDatabase do klasy nadrzędnej (dla testowanej metody) i ustawiliśmy odpowiedź zastępczą dla obiektu mockedDatabase - wiersz 6 powyżej (Mockito.doNothing (). When (mockDatabase) .updateScores ('student1', 220);)

Ważne punkty, na które należy zwrócić uwagę, to:

# 1) Obiekt mockowany musi skonfigurować odpowiedzi skrócone dla wszystkich metod, które zostaną wywołane podczas wykonywania funkcji.

#dwa) Parametry określone podczas tworzenia kodu pośredniczącego mogą być specyficzne lub ogólne.

Przykład w powyższym przypadku - określiliśmy parametry metody updateScores jako „student1” i 220, ponieważ wiemy, że są to dokładne dane wejściowe, za pomocą których zostanie wywołana nasza metoda.

# 3) Podczas weryfikacji sprawdzamy następujące elementy:

  • Została wywołana metoda mockDatabase.updateScores.
  • Argumentami były odpowiednio „student1” i 220.
  • Metoda updateScores została wywołana 1 raz.

Teraz spróbujmy nieco zmienić ten kod testowy i zobaczmy, co się stanie:

Zmienię argument w konfiguracji próbnej z „student1” na anyString (Mockito zapewnia standardowy element dopasowujący o nazwie anyString ()) & 220 na anyInteger (Mockito zapewnia standardowe dopasowanie o nazwie anyInt () i dopasowuje dowolną wartość całkowitą)

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }

Spróbuj ponownie uruchomić test, a test powinien nadal być zielony.

(Teraz spróbujmy zmienić weryfikację / potwierdzenia i zmienić dowolny z argumentów.

Zmieńmy 220 na 230. Teraz oczekuje się, że test zakończy się niepowodzeniem, ponieważ nie jest to oczekiwany argument, z którym musiała zostać wywołana baza danychUpdate.

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); }

Po uruchomieniu testu zapoznaj się z dziennikami błędów, jak pokazano poniżej (wyraźnie wspomina, że ​​rzeczywiste argumenty nie były zgodne z oczekiwanymi).

Argumenty są różne! Chciał:
mockDatabase.updateScores („student1”, 230);
-> at com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)

Rzeczywiste wywołanie ma różne argumenty:
mockDatabase.updateScores („student1”, 220);

Kod źródłowy

Interfejs - IDatabase.java

public interface IDatabase { public void updateScores(String studentId, int total); }

Testowana klasa - StudentScoreUpdates.java

public class StudentScoreUpdates { public IDatabase databaseImpl; public StudentScoreUpdates(IDatabase databaseImpl) { this.databaseImpl = databaseImpl; } public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for(int score : scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); } }

Klasa testów jednostkowych - StudentScoreUpdatesUnitTests.java

public class StudentScoreUpdatesUnitTests { @Mock public IDatabase mockDatabase; public StudentScoreUpdates studentScores; @BeforeEach public void beforeEach() { MockitoAnnotations.initMocks(this); } @Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); } }

Wniosek

To, co widzieliśmy do tej pory, jest bardzo prostym i prostym przykładem konfiguracji Mock przy użyciu środowiska Java Mockito.

W przypadku prawie 60-70% testów jednostkowych obejmujących makiety testy powinny mieć podobną strukturę. Mockito zapewnia wiele zaawansowanej konfiguracji / wsparcia dla rozległych potrzeb związanych z mockowaniem, wstrzykując fałszywe instancje za pomocą iniekcji zależności, zapewnia szpiegom rzeczywiste szpiegowanie prawdziwego wywołania metody i weryfikację wywołań.

Nasz nadchodzący samouczek wyjaśni więcej na temat koncepcji Mockito i szpiegów w Mockito.

NEXT Tutorial

rekomendowane lektury

^