Mockito: Próba szpiegowania metody wywołuje metodę oryginalną

Używam Mockito 1.9.0. Chcę kpić zachowanie dla jednej metody klasy w teście JUnit, więc mam

final MyClass myClassSpy = Mockito.spy(myInstance);
Mockito.when(myClassSpy.method1()).thenReturn(myResults);

Problem polega na tym, że w drugiej linii myClassSpy.method1()jest wywoływany, co powoduje wyjątek. Jedynym powodem, dla którego używam makiet, jest to, że później, przy każdym myClassSpy.method1()wywołaniu, nie zostanie wywołana prawdziwa metoda i myResultsobiekt zostanie zwrócony.

MyClassjest interfejsem i myInstancejest jego implementacją, jeśli to ma znaczenie.

Co muszę zrobić, aby poprawić to zachowanie szpiegowskie?

Pozwól mi zacytować oficjalną dokumentację :

Ważna uwaga na szpiegowanie prawdziwych obiektów!

Czasami nie można użyć, gdy (Obiekt) służy do karczowania szpiegów. Przykład:

List list = new LinkedList();
List spy = spy(list);

// Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
when(spy.get(0)).thenReturn("foo");

// You have to use doReturn() for stubbing
doReturn("foo").when(spy).get(0);

W twoim przypadku wygląda to tak:

doReturn(resulstIWant).when(myClassSpy).method1();

Moja sprawa różni się od przyjętej odpowiedzi. Próbowałem wyśmiewać metodę private-package dla instancji, która nie istniała w tym pakiecie

package common;

public class Animal {
  void packageProtected();
}

package instances;

class Dog extends Animal { }

i klasy testowe

package common;

public abstract class AnimalTest<T extends Animal> {
  @Before
  setup(){
    doNothing().when(getInstance()).packageProtected();
  }

  abstract T getInstance();
}

package instances;

class DogTest extends AnimalTest<Dog> {
  Dog getInstance(){
    return spy(new Dog());
  }

  @Test
  public void myTest(){}
}

Kompilacja jest poprawna, ale gdy próbuje skonfigurować test, zamiast tego wywołuje prawdziwą metodę.

Deklaracja metody chronionej lub publicznej rozwiązuje problem, ponieważ nie jest to czyste rozwiązanie.

W moim przypadku, używając Mockito 2.0, musiałem zmienić wszystkie any()parametry, aby zgasić nullable()prawdziwe połączenie.

Odpowiedź Tomasza Nurkiewicza wydaje się nie opowiadać całej historii!

Uwaga: wersja Mockito: 1.10.19.

Jestem bardzo nowicjuszem Mockito, więc nie potrafię wyjaśnić następującego zachowania: jeśli istnieje ekspert, który może poprawić tę odpowiedź, nie krępuj się.

Metoda, o której tu mowa getContentStringValue, NIE jest finali NIE static .

Linia ta ma wywołać oryginalną metodę getContentStringValue:

doReturn( "dummy" ).when( im ).getContentStringValue( anyInt(), isA( ScoreDoc.class ));

Ta linia nie wywołuje oryginalnej metody getContentStringValue:

doReturn( "dummy" ).when( im ).getContentStringValue( anyInt(), any( ScoreDoc.class ));

Z powodów, na które nie mogę odpowiedzieć, użycie isA()powoduje, że zamierzone (?) Działanie „nie wywoływać metody” doReturnnie powiodło się.

Spójrzmy na użyte tutaj podpisy metod: obie są staticmetodami Matchers. Obaj mówią Javadoc o powrocie null, co jest trochę trudne do opanowania w sobie. Prawdopodobnie Classobiekt przekazany podczas badania parametru jest badany, ale wynik nigdy nie jest obliczany ani odrzucany. Jeśli się uwzględninull może to oznaczać dowolną klasę i że liczysz na to, że wyśmiewana metoda nie zostanie wywołana, czy podpisy isA( ... )i any( ... )po prostu nie zwrócą się nullzamiast parametru ogólnego * <T>?

Tak czy siak:

public static <T> T isA(java.lang.Class<T> clazz)

public static <T> T any(java.lang.Class<T> clazz)

Dokumentacja API nie daje żadnych wskazówek na ten temat. Wydaje się również, że potrzeba takiego zachowania „nie wywoływać metody” jest „bardzo rzadka”. Ja osobiście używam tej techniki przez cały czas : zazwyczaj uważam, że kpina obejmuje kilka linii, które „ustawiają scenę” ... a następnie wywołuje metodę, która następnie „odtwarza” scenę w symulowanym kontekście, który wystawiłeś… Podczas gdy ustawiasz scenerię i rekwizyty, ostatnią rzeczą, jakiej pragniesz, jest, aby aktorzy weszli na scenę po lewej i zaczęli grać swoje serca ...

Ale to znacznie wykracza poza moją pensję ... Zapraszam wyjaśnienia od wszystkich przechodzących arcykapłanów Mockito ...

* czy „parametr ogólny” jest właściwym terminem?

Kolejnym możliwym scenariuszem, który może powodować problemy ze szpiegami, jest testowanie fasoli szparagowej (z ramą testu wiosennego) lub innej struktury, która przybliża obiekty podczas testu .

Przykład

@Autowired
private MonitoringDocumentsRepository repository

void test(){
    repository = Mockito.spy(repository)
    Mockito.doReturn(docs1, docs2)
            .when(repository).findMonitoringDocuments(Mockito.nullable(MonitoringDocumentSearchRequest.class));
}

W powyższym kodzie zarówno Spring, jak i Mockito będą próbowały proxy twojego obiektu MonitoringDocumentsRepository, ale Spring będzie pierwszy, co spowoduje prawdziwe wywołanie metody findMonitoringDocuments. Jeśli debugujemy nasz kod tuż po umieszczeniu szpiega w obiekcie repozytorium, będzie on wyglądał następująco:

repository = MonitoringDocumentsRepository$$EnhancerBySpringCGLIB$$MockitoMock$

@SpyBean na ratunek

Jeśli zamiast @Autowiredadnotacji użyjemy @SpyBeanadnotacji, rozwiążemy powyższy problem, adnotacja SpyBean również wstrzykuje obiekt repozytorium, ale najpierw będzie proxy przez Mockito i będzie wyglądać jak ten wewnątrz debuggera

repository = MonitoringDocumentsRepository$$MockitoMock$$EnhancerBySpringCGLIB$

a oto kod:

@SpyBean
private MonitoringDocumentsRepository repository

void test(){
    Mockito.doReturn(docs1, docs2)
            .when(repository).findMonitoringDocuments(Mockito.nullable(MonitoringDocumentSearchRequest.class));
}

Znalazłem jeszcze jeden powód, dla którego szpieg wywołuje oryginalną metodę.

Ktoś wpadł na pomysł, aby wyśmiewać finalklasę i dowiedział się o MockMaker:

Ponieważ działa to inaczej niż nasz obecny mechanizm, a ten ma inne ograniczenia i ponieważ chcemy zebrać doświadczenie i opinie użytkowników, ta funkcja musiała zostać wyraźnie aktywowana, aby była dostępna; można to zrobić za pomocą mechanizmu rozszerzenia mockito, tworząc plik src/test/resources/mockito-extensions/org.mockito.plugins.MockMakerzawierający jedną linię:mock-maker-inline

Źródło: https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2#mock-the-unmockable-opt-in-mocking-of-final-classesmethods

Po scaleniu i przeniesieniu tego pliku na mój komputer moje testy zakończyły się niepowodzeniem.

Musiałem tylko usunąć linię (lub plik) i spy()działałem.

Trochę późno na imprezę, ale powyższe rozwiązania nie działały dla mnie, więc dzielę się 0,02 $

Wersja Mokcito: 1.10.19

MyClass.java

private int handleAction(List<String> argList, String action)

Test.java

MyClass spy = PowerMockito.spy(new MyClass());

Poniższe NIE działało dla mnie (wywoływano rzeczywistą metodę):

1.

doReturn(0).when(spy , "handleAction", ListUtils.EMPTY_LIST, new String());

2)

doReturn(0).when(spy , "handleAction", any(), anyString());

3)

doReturn(0).when(spy , "handleAction", null, null);

Po DZIAŁANIU:

doReturn(0).when(spy , "handleAction", any(List.class), anyString());

Jednym ze sposobów upewnienia się, że metoda z klasy nie jest wywoływana, jest przesłonięcie metody za pomocą manekina.

    WebFormCreatorActivity activity = spy(new WebFormCreatorActivity(clientFactory) {//spy(new WebFormCreatorActivity(clientFactory));
            @Override
            public void select(TreeItem i) {
                log.debug("SELECT");
            };
        });

Odpowiedź dla użytkowników Scali: Nawet stawianie na doReturnpierwszym miejscu nie działa! Zobacz ten post .