Gereksiz Stubbing istisnası nasıl çözülür

Kodum aşağıdaki gibidir,

@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);

      }
}

İstisnanın altına düşüyorum

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)

Lütfen nasıl çözeceğime yardım et

Değiştir @RunWith(MockitoJUnitRunner.class)ile @RunWith(MockitoJUnitRunner.Silent.class).

İlk önce test mantığınızı kontrol etmelisiniz. Genellikle 3 vaka vardır. İlk olarak, yanlış yöntemle dalga geçiyorsunuz (bir yazım hatası yaptınız veya birisi test edilen kodu değiştirdi, böylece alay edilen yöntem artık kullanılmıyor). İkinci olarak, bu yöntem çağrılmadan önce testiniz başarısız oluyor. Üçüncüsü, kodun herhangi bir yerinde if / switch dalı mantığınız yanlış olur, böylece alay edilen yöntem çağrılmaz.

Bu ilk durumsa, kodda kullanılan için her zaman alay edilen yöntemi değiştirmek istersiniz. İkinci ve üçüncü duruma göre değişir. Genellikle bu taklidi, faydası yoksa silmelisiniz. Ancak bazen parametrik testlerde bu farklı yolu izlemesi veya daha önce başarısız olması gereken belirli durumlar vardır. Sonra bu testi iki veya daha fazla ayrı sınava bölebilirsiniz, ancak bu her zaman iyi görünmüyor. Muhtemelen 3 bağımsız değişken içeren 3 test yöntemi, test etmenizi okunamaz hale getirebilir. Bu durumda JUnit 4 için bu istisnayı,

@RunWith(MockitoJUnitRunner.Silent.class) 

ek açıklama veya kural yaklaşımı kullanıyorsanız

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

veya (aynı davranış)

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

JUnit 5 testleri için, mockito-junit-jupiterpakette sağlanan ek açıklamayı kullanarak bu istisnayı susturabilirsiniz .

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

Sessizlik bir çözüm değil. Testinde taklidini düzeltmen gerekiyor. Resmi belgelere buradan bakın .

Gereksiz saplamalar, test yürütme sırasında asla gerçekleştirilemeyen saplama yöntem çağrılarıdır (ayrıca bkz.MockitoHint), örnek:

//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
 ...

Test yürütme sırasında test edilen kodda hiçbir zaman stublanmış yöntemlerden birinin gerçekleştirilmediğine dikkat edin. Başıboş saplama, geliştiricinin bir gözetiminden, kopyala-yapıştır yapısından veya testi / kodu anlamayan etkiden kaynaklanıyor olabilir. Her iki durumda da, geliştirici gereksiz test koduyla sonuçlanır. Kod tabanını temiz ve sürdürülebilir tutmak için, gereksiz kodların kaldırılması gerekir. Aksi takdirde testleri okumak ve akıl yürütmek daha zordur.

Kullanılmayan saplamaları tespit etme hakkında daha fazla bilgi için MockitoHint'e bakın.

Benim için ne @Rulene de @RunWith(MockitoJUnitRunner.Silent.class)öneriler işe yaradı. Mockito-core 2.23.0'a yükselttiğimiz eski bir projeydi.

Şunları UnnecessaryStubbingExceptionkullanarak kurtulabiliriz :

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

onun yerine:

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

Söylemeye gerek yok, test koduna bakmayı tercih etmelisiniz, ancak her şeyden önce derlenen ve testleri çalıştırmaya ihtiyacımız vardı;)

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

whenBurada bir şeyler yapmak site taklidinin yapılandırır. Ancak bu taklidi bu satırdan sonra herhangi bir şekilde kullanmıyorsunuz (a yapmak dışında verify). Mockito, whenbu nedenle çizginin anlamsız olduğu konusunda sizi uyarır . Belki bir mantık hatası yaptınız?

Yığın izlemenizin bir kısmına baktığınızda, dao.doSearch()başka bir yere saplıyormuşsunuz gibi görünür . Daha çok aynı yöntemin taslaklarını tekrar tekrar oluşturmak gibi.

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.

Örneğin aşağıdaki Test Sınıfını düşünün:

@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();
    }
}

Gerektiğinde testlerinizi yeniden düzenlemeyi tercih ederim.

Eh, Benim durumumda mockito hata sonrasında gerçek bir yöntemi çağırmak için bana söylüyordu whenya wheneversaplama. Az önce alay ettiğimiz koşulları çağırmadığımız için, Mockito bunu gereksiz saplamalar veya kod olarak bildiriyordu.

İşte hata geldiği zamanki gibiydi:

@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)
}

daha sonra, yöntemle alay etmek için when ifadesinde belirtilen gerçek yöntemi çağırdım.

yapılan değişiklikler aşağıdaki gibidir 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)
}

şuan çalışıyor.

Bunun yerine bu stili kullanıyorsanız:

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

şununla değiştir:

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

Ben UnnecessaryStubbingExceptionkullandığım çalıştığında whenbir casus nesne üzerinde yöntemleri. Mockito.lenient()istisnayı susturdu ancak test sonuçları doğru değildi.

Casus nesneler söz konusu olduğunda, yöntemlerin doğrudan çağrılması gerekir.

@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);
    }
}

Değiştir

@RunWith(MockitoJUnitRunner.class)

ile

@RunWith(MockitoJUnitRunner.Silent.class)

veya kaldır@RunWith(MockitoJUnitRunner.class)

veya sadece istenmeyen alaycı çağrıları yorumlayın (yetkisiz stubing olarak gösterilir).

Büyük bir proje olması durumunda, bu istisnaların her birini düzeltmek zordur. Aynı zamanda kullanarakSilent tavsiye edilmez. Bunların bir listesi verilen tüm gereksiz izleri kaldırmak için bir komut dosyası yazdım.

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

Sadece mvnçıktıyı kopyalayıp yapıştırmamız ve bu istisnaların listesini regex kullanarak yazmamız ve betiğin gerisini halletmesine izin vermemiz gerekiyor.

Bir sahte oluşturduğunuzda ve bu sahte kullanılmadığında, kullanılmayan saplama istisnası atar. Senin durumunda bu sahte aslında çağrılmaz. Bu nedenle o hatayı atıyor. Bu nedenle, relpace @RunWith(MockitoJUnitRunner.class)ile @RunWith(MockitoJUnitRunner.Silent.class)hata çıkarıyoruz. Hala kullanmak @RunWith(MockitoJUnitRunner.class)istiyorsanız, alay ettiğiniz işlev gerçekten çağrılıyorsa veya çağrılmıyorsa mantığınızda hata ayıklamayı deneyin.

Alay ederken herhangi () kullanırsanız, @RunWith(MockitoJUnitRunner.class)ile yeniden boşluk bırakmanız gerekir @RunWith(MockitoJUnitRunner.Silent.class).