Menu

12 najpopularniejszych pytań do wywiadu Mockito (wywiady z mocking Framework)

  • Główny
  • Inny
  • 12 najpopularniejszych pytań do wywiadu Mockito (wywiady z mocking Framework)

top 12 mockito interview questions

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Najczęściej zadawane pytania do wywiadu z Mockito, aby złamać wywiad z Mockito:

W naszym poprzednim samouczku dowiedzieliśmy się Prywatne, statyczne i puste metody kpiny . Przeczytaj ukończyć samouczki szkoleniowe na Mockito dla pełnego zrozumienia struktury Mockito.

W tym artykule omówiono najczęściej zadawane typowe pytania do wywiadów w ramach Mockito Mocking.

Oczekuje się, że każdy programista lub QA będzie znać podstawy Mockowania, aby z łatwością napisać większość testów białoskrzynkowych (lub testów jednostkowych) i symulować zależności w celu zwiększenia pokrycia kodu i większego zaufania do aplikacji.

Pytania do wywiadu Mockito

Najpopularniejsze pytania do wywiadu Mockito ze szczegółowymi odpowiedziami

Poniżej wymieniono najczęściej zadawane pytania na temat ram makietowych.

Pytanie 1) Dlaczego potrzebujemy kpiny?

Odpowiedź: Istnieje wiele przypadków użycia kpiny, które pomagają w testowaniu jednostkowym kodu w izolacji i sprawiają, że test jest wysoce powtarzalny i przewidywalny.

Mockowanie jest generalnie wymagane, gdy:

do) Testowany komponent ma zależności, które nie zostały jeszcze zaimplementowane lub trwa implementacja.

Dobrym przykładem może być punkt końcowy interfejsu API REST, który będzie dostępny później w pewnym momencie, ale wykorzystałeś go w kodzie za pośrednictwem zależności.

Ponieważ rzeczywista implementacja nadal nie jest dostępna, przez większość czasu naprawdę wiesz, jaka jest oczekiwana odpowiedź tego interfejsu API. Mocks umożliwia przetestowanie tego typu integracji.

b) Komponent aktualizuje stan w systemie.

Przykład: Wywołania DB - nie chciałbyś aktualizować swojej bazy danych danymi, które są tylko do celów testowych. Może to spowodować uszkodzenie danych, co więcej, dostępność bazy danych jest kolejnym wyzwaniem podczas wykonywania testu.

W ten sposób, aby uniknąć takiego zachowania, wywołania DB mogą być mockowane w testowanym komponencie. W związku z tym nie ma bezpośredniego sprzężenia DB i badanego elementu.

Q # 2) Różnica między doReturn a thenReturn.

Odpowiedź: Mockito udostępnia dwie różne składnie do tworzenia kodów pośredniczących, takich jak:

  • doReturn, a następnieReturn
  • nic nie robić (nie wtedy nic)
  • doThrow, a następnie Throw

Obie te metody konfigurują kody pośredniczące i mogą być używane do tworzenia / konfigurowania kodów pośredniczących i mogą być czasami używane zamiennie.

narzędzie do naprawy błędów systemu Windows Windows 10

Więc czym one się różnią?

do) Metoda thenReturn tworzenia kodów pośredniczących jest bezpiecznym dla typu sposobem konfigurowania kodów pośredniczących. Zasadniczo oznacza to, że sprawdza w czasie kompilacji zwracane typy, które również chcesz odgiąć.

Zrozummy to na przykładzie:

Przyjmij metodę getItemDetails na mockedItemService która zwraca obiekt typu ItemSku. Więc z następnie Return, nie będziesz mógł zwrócić niczego innego niż typu ItemSku, ale za pomocą doReturn możesz skonfigurować kod pośredniczący, aby zwracał cokolwiek, a test zakończy się niepowodzeniem (lub zgłosi wyjątek) podczas wykonywania.

// Pracuje

when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());

// zgłasza wyjątek czasu kompilacji

when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);

// w przypadku metody doReturn oba ustawienia pośredniczące działają, ponieważ nie są bezpieczne w kompilacji.

// tutaj próbujemy zwrócić obiekt typu double, który nadal działa i nie generuje żadnego ostrzeżenia o czasie kompilacji.

doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));

b) Inna ważna różnica między tymi dwoma drogami do kodu pośredniego dotyczy obiektów Mocked, poza bezpieczeństwem kompilacji nie ma dużej różnicy.

Jednak w przypadku obiektów szpiegowskich konfiguracja pośrednicząca typu „thenReturn” nie zadziała, ponieważ spowoduje wywołanie metody rzeczywistej przed zwróceniem odpowiedzi jako wywołanie, a nie w przypadku Mocka, ale w przypadku Spy, który opakowuje instancję rzeczywistego obiektu .

Więc przypuśćmy, że jest szpieg o imieniu spiedObject i ma metodę testMethod, która zwraca liczbę całkowitą, a następnie aby ustawić kod pośredniczący, będziesz musiał użyć doReturn zamiast thenReturn.

doReturn (10).when(spiedObject.testMethod());

P # 3) Kiedy i dlaczego należy używać szpiega?

Odpowiedź: Szpieg to rodzaj częściowej makiety obsługiwanej przez Mockito.

Zasadniczo oznacza to rodzaj wystąpienia, w którym:

do) Gdy żadna próba nie jest skonfigurowana, każda interakcja ze szpiegiem skutkuje wywołaniem prawdziwych metod. Ale nadal pozwala zweryfikować interakcje ze szpiegowanym obiektem, np. - czy metoda została faktycznie wywołana, ile razy metoda została wywołana, jakie były argumenty, przy użyciu których została wywołana metoda itp.

b) Zapewnia elastyczność konfiguracji częściowych prób.

Na przykład, jeśli masz obiekt z dwiema metodami - metoda1 i metoda2 i chcesz, aby wywoływano metodę1 i mockowano metodę2. Szpiedzy zapewniają taką konfigurację.

Tak więc różnica między makietą a kodem pośrednim w prostych słowach jest taka, że ​​makieta jest tworzona z typu, a nie z instancji, podczas gdy kod pośredniczący otacza rzeczywistą instancję obiektu klasy.

Pytanie 4) Dlaczego nie można wyszydzać metod statycznych za pomocą Mockito?

cykliczna lista połączona c ++

Odpowiedź: Metody statyczne są skojarzone z samą klasą, a nie z konkretnym wystąpieniem klasy. Oznacza to, że wszystkie instancje / obiekty klasy używają tego samego wystąpienia metody statycznej.

Metody statyczne są bardziej podobne do kodu proceduralnego i są zwykle używane w starszych systemach.

Biblioteki pozorowane zazwyczaj tworzą mocky poprzez dynamiczne tworzenie instancji w czasie wykonywania, za pośrednictwem interfejsów lub przez dziedziczenie, a ponieważ metoda statyczna nie jest powiązana z żadną konkretną instancją, nie jest możliwe, aby symulować struktury (takie jak mockito, easy mock itp.), Aby symulować metody statyczne.

Struktury takie jak PowerMock, które obsługują metody statyczne, wykonują manipulację kodem bajtowym w czasie wykonywania w celu symulowania metod statycznych.

P # 5) Jaka jest potrzeba sprawdzenia, czy została wywołana próba?

Odpowiedź: Skonfigurowanie kodu pośredniczącego na fałszywym obiekcie (lub szpiegowanej instancji) nie gwarantuje, że konfiguracja pośrednicząca została w ogóle wywołana.

„Weryfikacyjne” dopasowania, dają możliwość sprawdzenia, czy utworzony kod pośredniczący został faktycznie wywołany, czy nie, ile razy wykonano wywołanie, z jakimi argumentami wywołano metodę skrótową itp.

Zasadniczo pozwala nam to zweryfikować konfigurację testu i oczekiwany wynik w bardziej solidny sposób.

P # 6) Co to jest dobry testowalny kod?

Odpowiedź:

Kilka punktów dotyczących testowalnego kodu (co oznacza, że ​​można go łatwo przetestować jednostkowo) obejmuje:

  • Zmniejszona liczba zależności lub ścisłe połączenie - Przykład: Zależności powinny być wstrzykiwane, a nie bezpośrednio tworzone.
  • Kod zgodny z SRP (zasada pojedynczej odpowiedzialności) - Zasadniczo oznacza to, że klasa nie powinna mieć wielu powodów do zmiany. Zgodność z SRP pozwala uniknąć klas tworzących zależność od siebie i zapewnia spójność i przejrzystość kodu.
  • Mniejsze / minimalne użycie metod statycznych i klas końcowych - Zazwyczaj wskazują one na zapachy kodu i były najczęściej kojarzone ze starszym kodem.

P # 7) Jakie są ograniczenia Mockito?

Odpowiedź: Mockito to platforma z wyboru dla większości projektów opartych na Javie. Jest łatwy do wdrożenia, czytania i zrozumienia.

Oto niektóre z wad lub ograniczeń funkcjonalności:

  • Brak możliwości wyśmiewania metod statycznych.
  • Konstruktory, metody prywatne i klasy końcowe nie mogą być wyśmiewane.

P # 8) Które frameworki obsługują mockowanie metod prywatnych i statycznych?

Odpowiedź: Struktury takie jak PowerMockito (rozszerzenia frameworka Mockito), JMockit itp. Zapewniają środki do mockowania metod prywatnych i statycznych.

Q # 9) Mockowanie / Stubbing domyślnych metod w interfejsie w Javie 8.

Odpowiedź: Dzięki implementacji metod domyślnych w interfejsie Java 8, Mockito zapewnia gotową obsługę mockowania takich metod domyślnych. (Należy pamiętać, że ta obsługa została wprowadzona począwszy od Mockito 2).

Te metody mogą być mockowane / zastępowane, tak jak inne metody klasy lub interfejsu.

P # 10) W jaki sposób można zweryfikować kolejność wywołań pośrednich w Mockito?

Odpowiedź: Jeśli chcesz zweryfikować kolejność wywoływania prób, Mockito „ W porządku ”Można użyć interfejsu.

Podczas testu wystarczy ustawić / utworzyć obiekt Inorder, wypisując listę pozorowanych obiektów, na których należy ustalić kolejność makiet (jeśli istnieje wiele metod na tej samej makiecie i nie ma innej makiety wymagającej do weryfikacji wystarczy tylko raz wspomnieć o wyśmiewanej klasie).

Rozważ poniższy test, który definiuje obiekt InOrder i wspomina 2 wystąpienia mockDatabaseImpl

jak otwierać pliki bin w systemie Windows 7
@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); }

Również w celach informacyjnych wypisanie kodu testowanej metody będzie pomocne w zrozumieniu kolejności wykonywania testu:

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); databaseImpl.getGrade(total); }

Jak widać powyżej, databaseImpl najpierw wywołuje updateScores, a następnie getGrade.

Tak więc, jeśli piszesz test jednostkowy przy użyciu Mockito, w tym celu i musisz zapewnić kolejność wywołań w databaseImpl, zapoznaj się z kodem testu i upewnij się, że potwierdzenia są wykonane zgodnie z oczekiwaną kolejnością.

W powyższym przykładzie, jeśli zmienię kolejność potwierdzeń, spowoduje to niepowodzenie testu z wyjątkiem „VerificationInOrderFailure”.

Po zmianie kolejności potwierdzenia kod wygląda tak, jak pokazano poniżej:

@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); }

Powyższe wykonanie testu zgłasza wyjątek o typie:

„VerificationInOrderFailure” org.mockito.exceptions.verification.VerificationInOrderFailure:
Weryfikacja w przypadku niepowodzenia zamówienia
Poszukiwany, ale nie przywołany:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)

Q # 11) Zwracanie wielu wartości w stosunku do kolejnych wywołań metod

Odpowiedź: Aby zwrócić różne wartości dla wielu wywołań tej samej metody, Mockito zapewnia 3 podejścia, jak podano poniżej:

do) Używając oddzielonych przecinkami: Działa to z thenReturn.

Na przykład Biorąc powyższy przykład kodu, spróbujmy ustawić kolejny kod pośredniczący dla metody - getGrade, który zwróci różne wartości w zależności od sekwencji iteracji:

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');

Oznacza to, że gdy metody getGrade zostaną wywołane w testowanej metodzie, pierwsze wywołanie zwróci „A”, drugie wywołanie zwróci „B” i tak dalej.

b) Konsekutywne, a następnie Zwrot: Jest to podejście powiązane z instrukcjami thenReturn. Zastosowanie połączonych wywołań do tego samego przykładu będzie wyglądać tak, jak pokazano poniżej.

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');

c) Konsekutywny doReturn: Ostatnim podejściem jest użycie doReturn w łańcuchowym formacie, jak powyżej.

doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())

P # 12) Jakie są różne typy frameworków do mockowania i jak one działają?

Odpowiedź: Rodzaje frameworka mockującego i sposób ich działania wyjaśniono poniżej.

Istnieją zasadniczo 2 kategorie frameworków:

  1. Oparte na proxy - Przykład, Mockito, EasyMock itp.
  2. Na podstawie kodu bajtowego - Przykład, PowerMock, JMockit itp.

Porównajmy obie te struktury pod kątem różnych parametrów.

Oparte na proxyNa podstawie kodu bajtowego
Po prostuProstsze i łatwiejsze w użyciuMoże wiązać się ze złożoną logiką konfiguracji próbnej
Sposób tworzeniaTworzony jest serwer proxy lub fałszywy obiekt, który w rzeczywistości nie wymaga wystąpienia klasy / interfejsuZasadniczo polega na tworzeniu obiektów i manipulowaniu instancjami w czasie wykonywania dla zachowania pozorowanego / pośredniczącego
FunkcjonalnośćMockowanie klas i interfejsówOprócz klas i interfejsów umożliwia mockowanie metod statycznych, klas końcowych itp
Zależność JavaNiezbyt ściśle powiązany z wersjami JavaPonieważ te struktury wymagają manipulacji kodem bajtowym, są ściśle powiązane i mogą nie być kompatybilne wstecz / do przodu w wersjach Java.
PrzykładyMockito, EasyMock itp.PowerMock, JMockit itp.

Wniosek

Treść omawiana w tym artykule służy do podstawowych dyskusji na temat frameworków Mocking, aw szczególności przygotowania do wywiadów Mockito.

Oprócz teoretycznego zrozumienia omawianych pytań, należy również spróbować zrobić przykłady z prawdziwego kodu, co sprawi, że nauka tych frameworków będzie ciekawsza i przyjemniejsza.

Mam nadzieję, że podobał Ci się cały zakres samouczków z tej serii Mockito.

Przyjemnej nauki.

POPRZEDNIA samouczek | PIERWSZY samouczek

rekomendowane lektury

^