Jak rozwiązać niepotrzebny wyjątek zatarcia

Mój kod jest jak poniżej,

@RunWith(MockitoJUnitRunner.class)
public class MyClass {

    private static final String code ="Test";

    @Mock
     private MyClassDAO dao;

    @InjectMocks
     private MyClassService Service = new MyClassServiceImpl();

    @Test
     public void testDoSearch() throws Exception {
         final String METHOD_NAME = logger.getName().concat(".testDoSearchEcRcfInspections()");
         CriteriaDTO dto = new CriteriaDTO();
         dto.setCode(code);
         inspectionService.searchEcRcfInspections(dto);
         List<SearchCriteriaDTO> summaryList = new ArrayList<SearchCriteriaDTO>();
         inspectionsSummaryList.add(dto);
         when(dao.doSearch(dto)).thenReturn(inspectionsSummaryList);//got error in this line
         verify(dao).doSearchInspections(dto);

      }
}

Jestem poniżej wyjątku

org.mockito.exceptions.misusing.UnnecessaryStubbingException: 
Unnecessary stubbings detected in test class: Test
Clean & maintainable test code requires zero unnecessary code.
Following stubbings are unnecessary (click to navigate to relevant line of code):
  1. -> at service.Test.testDoSearch(Test.java:72)
Please remove unnecessary stubbings or use 'silent' option. More info: javadoc for UnnecessaryStubbingException class.
  at org.mockito.internal.exceptions.Reporter.formatUnncessaryStubbingException(Reporter.java:838)
  at org.mockito.internal.junit.UnnecessaryStubbingsReporter.validateUnusedStubs(UnnecessaryStubbingsReporter.java:34)
  at org.mockito.internal.runners.StrictRunner.run(StrictRunner.java:49)
  at org.mockito.junit.MockitoJUnitRunner.run(MockitoJUnitRunner.java:103)
  at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
  at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
  at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

Pomóż mi, jak to rozwiązać

Wymień @RunWith(MockitoJUnitRunner.class)się @RunWith(MockitoJUnitRunner.Silent.class).

Najpierw sprawdź logikę testu. Zwykle są 3 przypadki. Po pierwsze, kpisz z niewłaściwej metody (popełniłeś literówkę lub ktoś zmienił testowany kod, tak że fałszywa metoda nie jest już używana). Po drugie, test kończy się niepowodzeniem przed wywołaniem tej metody. Po trzecie, twoja logika popada w błąd, jeśli / switch gałąź gdzieś w kodzie, więc mockowana metoda nie zostanie wywołana.

Jeśli jest to pierwszy przypadek, zawsze chcesz zmienić mockowaną metodę na używaną w kodzie. Z drugim i trzecim to zależy. Zwykle powinieneś po prostu usunąć tę makietę, jeśli nie ma ona zastosowania. Ale czasami w sparametryzowanych testach są pewne przypadki, które powinny pójść tą inną ścieżką lub zakończyć się niepowodzeniem wcześniej. Następnie możesz podzielić ten test na dwa lub więcej oddzielnych, ale nie zawsze wygląda to dobrze. 3 metody testowe z maksymalnie 3 argumentami, które dostawcy mogą sprawić, że test będzie wyglądał nieczytelnie. W takim przypadku dla JUnit 4 możesz wyciszyć ten wyjątek z jednym i drugim

@RunWith(MockitoJUnitRunner.Silent.class) 

adnotacja lub jeśli używasz podejścia regułowego

@Rule
public MockitoRule rule = MockitoJUnit.rule().strictness(Strictness.LENIENT);

lub (to samo zachowanie)

@Rule
public MockitoRule rule = MockitoJUnit.rule().silent();

W przypadku testów JUnit 5 można wyciszyć ten wyjątek za pomocą adnotacji dostarczonej w mockito-junit-jupiterpakiecie.

@ExtendWith(MockitoExtension.class)
@MockitoSettings(strictness = Strictness.LENIENT)
class JUnit5MockitoTest {
}

Milczenie nie jest rozwiązaniem. Musisz poprawić swoją próbę w swoim teście. Zobacz oficjalną dokumentację tutaj .

Niepotrzebne kody pośredniczące to wywołania metod, które nigdy nie zostały zrealizowane podczas wykonywania testu (zobacz także MockitoHint), przykład:

//code under test:
 ...
 String result = translator.translate("one")
 ...

 //test:
 ...
 when(translator.translate("one")).thenReturn("jeden"); // <- stubbing realized during code execution
 when(translator.translate("two")).thenReturn("dwa"); // <- stubbing never realized
 ...

Zauważ, że jedna z metod skrótowych nigdy nie została zrealizowana w testowanym kodzie podczas wykonywania testu. Zagubiony fragment może być przeoczeniem dewelopera, artefaktem kopiowania i wklejania lub skutkiem niezrozumienia testu / kodu. Tak czy inaczej, programista kończy z niepotrzebnym kodem testowym. Aby baza kodu była czysta i łatwa do utrzymania, konieczne jest usunięcie niepotrzebnego kodu. W przeciwnym razie testy są trudniejsze do odczytania i uzasadnienia.

Aby dowiedzieć się więcej o wykrywaniu nieużywanych kiczów, zobacz MockitoHint.

U mnie ani te, @Ruleani @RunWith(MockitoJUnitRunner.Silent.class)sugestie nie zadziałały. To był starszy projekt, w którym zaktualizowaliśmy do mockito-core 2.23.0.

Mogliśmy się go pozbyć UnnecessaryStubbingExceptionza pomocą:

Mockito.lenient().when(mockedService.getUserById(any())).thenReturn(new User());

zamiast:

when(mockedService.getUserById(any())).thenReturn(new User());

Nie trzeba dodawać, że powinieneś raczej spojrzeć na kod testowy, ale musieliśmy najpierw skompilować rzeczy i testy;)

 when(dao.doSearch(dto)).thenReturn(inspectionsSummaryList);//got error in this line
 verify(dao).doSearchInspections(dto);

whenTutaj konfiguruje makiety coś zrobić. Jednak po tej linijce nie używasz już w żaden sposób tej makiety (poza zrobieniem a verify). Mockito ostrzega, że ​​w whenzwiązku z tym linia jest bezcelowa. Być może popełniłeś błąd logiczny?

Patrząc na część śladu stosu, wygląda na to, że przegrywasz dao.doSearch()gdzie indziej. Bardziej przypomina wielokrotne tworzenie kodów pośredniczących tej samej metody.

Following stubbings are unnecessary (click to navigate to relevant line of code):
  1. -> at service.Test.testDoSearch(Test.java:72)
Please remove unnecessary stubbings or use 'silent' option. More info: javadoc for UnnecessaryStubbingException class.

Rozważ na przykład poniższą klasę testową:

@RunWith(MockitoJUnitRunner.class)
public class SomeTest {
    @Mock
    Service1 svc1Mock1;

    @Mock
    Service2 svc2Mock2;

    @InjectMock
    TestClass class;

    //Assume you have many dependencies and you want to set up all the stubs 
    //in one place assuming that all your tests need these stubs.

    //I know that any initialization code for the test can/should be in a 
    //@Before method. Lets assume there is another method just to create 
    //your stubs.

    public void setUpRequiredStubs() {
        when(svc1Mock1.someMethod(any(), any())).thenReturn(something));
        when(svc2Mock2.someOtherMethod(any())).thenReturn(somethingElse);
    }

    @Test
    public void methodUnderTest_StateUnderTest_ExpectedBehavior() {
        // You forget that you defined the stub for svcMock1.someMethod or 
        //thought you could redefine it. Well you cannot. That's going to be 
        //a problem and would throw your UnnecessaryStubbingException.
       when(svc1Mock1.someMethod(any(),any())).thenReturn(anyThing);//ERROR!
       setUpRequiredStubs();
    }
}

Wolałbym raczej rozważyć refaktoryzację twoich testów, aby zablokować je w razie potrzeby.

Jeśli zamiast tego używasz tego stylu:

@Rule
public MockitoRule rule = MockitoJUnit.rule().strictness(Strictness.STRICT_STUBS);

zamień na:

@Rule
public MockitoRule rule = MockitoJUnit.rule().silent();

Miałem, UnnecessaryStubbingExceptiongdy próbowałem użyć whenmetod na obiekcie szpiegowskim. Mockito.lenient()wyciszył wyjątek, ale wyniki testu były nieprawidłowe.

W przypadku obiektów Spy należy wywołać metody bezpośrednio.

@ExtendWith(MockitoExtension.class)
@RunWith(JUnitPlatform.class)
class ArithmTest {

    @Spy
    private Arithm arithm;

    @Test
    void testAddition() {

        int res = arithm.add(2, 5);

        // doReturn(7).when(arithm).add(2, 5);
        assertEquals(res, 7);
    }
}

Cóż, w moim przypadku błąd Mockito mówił mi, żebym wywołał właściwą metodę po whenlubwhenever . Ponieważ nie wywoływaliśmy warunków, z których przed chwilą wyśmiewaliśmy, Mockito zgłosił to jako niepotrzebne kody pośredniczące lub kod.

Oto jak to było, kiedy nadchodził błąd:

@Test
fun `should return error when item list is empty for getStockAvailability`() {
    doAnswer(
        Answer<Void> { invocation ->
            val callback =
                invocation.arguments[1] as GetStockApiCallback<StockResultViewState.Idle, StockResultViewState.Error>
            callback.onApiCallError(stockResultViewStateError)
            null
        }
    ).whenever(stockViewModelTest)
        .getStockAvailability(listOf(), getStocksApiCallBack)
}

następnie właśnie wywołałem właściwą metodę wspomnianą w instrukcji when, aby kpić z metody.

wprowadzone zmiany są jak poniżej stockViewModelTest.getStockAvailability(listOf(), getStocksApiCallBack)

@Test
fun `should return error when item list is empty for getStockAvailability`() {
    doAnswer(
        Answer<Void> { invocation ->
            val callback =
                invocation.arguments[1] as GetStockApiCallback<StockResultViewState.Idle, StockResultViewState.Error>
            callback.onApiCallError(stockResultViewStateError)
            null
        }
    ).whenever(stockViewModelTest)
        .getStockAvailability(listOf(), getStocksApiCallBack)
    //called the actual method here
    stockViewModelTest.getStockAvailability(listOf(), getStocksApiCallBack)
}

już działa.

Zastąpić

@RunWith(MockitoJUnitRunner.class)

z

@RunWith(MockitoJUnitRunner.Silent.class)

lub usuń@RunWith(MockitoJUnitRunner.class)

lub po prostu zakomentuj niechciane kpiące połączenia (pokazane jako nieautoryzowane stubbing).

W przypadku dużego projektu trudno jest naprawić każdy z tych wyjątków. W tym samym czasie, używającSilent nie zaleca się . Napisałem skrypt, aby usunąć wszystkie niepotrzebne karczowce, podając ich listę.

https://gist.github.com/cueo/da1ca49e92679ac49f808c7ef594e75b

Musimy tylko skopiować i wkleić mvnwynik i napisać listę tych wyjątków za pomocą wyrażenia regularnego, a skrypt zajmie się resztą.

Jeśli używasz any () podczas mockowania, musisz zamienić miejsce @RunWith (MockitoJUnitRunner.class) z @RunWith (MockitoJUnitRunner.Silent.class).

Kiedy tworzysz makietę i ta makieta nie jest używana, zgłasza nieużywany wyjątek stubbing. W twoim przypadku ten mock nie jest faktycznie wywoływany. Dlatego rzuca ten błąd. W związku @RunWith(MockitoJUnitRunner.class)z @RunWith(MockitoJUnitRunner.Silent.class)tym zmiana miejsca z którą usunie błąd. Jeśli nadal chcesz użyć, @RunWith(MockitoJUnitRunner.class)spróbuj debugować swoją logikę, jeśli funkcja, którą mockujesz, jest faktycznie wywoływana, czy nie.