streamalism.org

1. Overzicht

In deze korte tutorial maken we kennis met de Mockito OnnodigStubbingException. Deze uitzondering is een van de meest voorkomende uitzonderingen die we waarschijnlijk tegenkomen wanneer we stubs onjuist gebruiken.

We beginnen met het uitleggen van de filosofie achter strikte stubbing en waarom Mockito het gebruik ervan standaard aanmoedigt. Vervolgens bekijken we wat deze uitzondering precies inhoudt en onder welke omstandigheden deze kan optreden. Tot slot zullen we een voorbeeld zien van hoe we deze uitzondering in onze tests kunnen onderdrukken.

Bekijk onze uitgebreide Mockito-serie voor meer informatie over testen met Mockito.

2. Strikt stoten

Met versie 1.x van Mockito was het mogelijk om zonder enige beperking te configureren en ermee te communiceren. Dit betekende dat tests na verloop van tijd vaak te gecompliceerd werden en soms moeilijker te debuggen.

Sinds versie 2. +, Mockito heeft nieuwe functies geïntroduceerd die het raamwerk naar "striktheid" duwen. De belangrijkste doelen hierachter zijn:

• Detecteer ongebruikte stubs in de testcode
• Verminder het dupliceren van testcodes en de onnodige testcode
• Promoot schonere tests door ‘dode 'code te verwijderen
• Help de foutopsporing en productiviteit te verbeteren

Door deze principes te volgen, kunnen we schonere tests maken door onnodige testcode te elimineren. Ze helpen ook om kopieer- en plakfouten te voorkomen, evenals andere onoplettende ontwikkelaars.

Samenvattend, streng stubbing rapporteert onnodige stubs, detecteert niet-overeenkomende stubbing-argumenten en maakt onze tests DROGER (Don't Repeat Yourself). Dit maakt een schone en onderhoudbare codebase mogelijk.

2.1. Strict Stubs configureren

Sinds Mockito 2. + wordt strikt stubbing standaard gebruikt bij het initialiseren van onze spot met een van de volgende:

• MockitoJUnitRunner
• MockitoJUnit.rule ()

Mockito raadt ten zeerste het gebruik van een van de bovenstaande opties aan. Er is echter ook een andere manier om strikte stubbing in onze tests mogelijk te maken wanneer we geen gebruik maken van de Mockito-regel of hardloper:

Mockito.mockitoSession () .initMocks (dit) .strictness (Strictness.STRICT_STUBS) .startMocking (); 

Een laatste belangrijk punt om te maken is dat in Mockito 3.0 alle stubbings "strikt" zullen zijn en standaard gevalideerd.

3. OnnodigStubbingException Voorbeeld

Simpel gezegd, een onnodige stub is een afgebroken methodeaanroep die nooit is gerealiseerd tijdens het uitvoeren van een test.

Laten we een eenvoudig voorbeeld bekijken:

@Test openbare leegte gegevenUnusedStub_whenInvokingGetThenThrowUnnnoodzakelijkStubbingException () {when (mockList.add ("één")). ThenReturn (true); // dit wordt niet aangeroepen wanneer (mockList.get (anyInt ())). thenReturn ("hallo"); assertEquals ("Lijst moet hallo bevatten", "hallo", mockList.get (1)); }

Wanneer we deze unit-test uitvoeren, zal Mockito de ongebruikte stub detecteren en een OnnodigStubbingException:

org.mockito.exceptions.misusing.UnnnoodzakelijkStubbingException: onnodige stubbings gedetecteerd. Schone en onderhoudbare testcode vereist nul onnodige code. De volgende stubbings zijn niet nodig (klik om naar de relevante regel code te navigeren): 1. -> at com.baeldung.mockito.misusing.MockitoUnnodigStubUnitTest.givenUnusedStub_whenInvokingGetThenThrowUnnnodigStubbingException (MockitoUnubbuallyStubUnitTest.java:37) striktheid verwijderen of verwijderen. Meer info: javadoc voor klasse UnnnodigStubbingException.

Gelukkig wordt uit de foutmelding duidelijk wat hier het probleem is. We kunnen ook zien dat het uitzonderingsbericht ons zelfs naar de exacte regel verwijst die de fout veroorzaakt.

Waarom gebeurt dit? Nou, de eerste wanneer aanroep configureert onze mock om terug te keren waar wanneer we de toevoegen methode met het argument "een". We gebruiken deze methode echter niet tijdens de rest van de uitvoering van de unit-test.

Mockito vertelt ons dat onze eerste wanneer lijn is overbodig en misschien hebben we een fout gemaakt bij het configureren van onze stubs.

Hoewel dit voorbeeld triviaal is, is het gemakkelijk voor te stellen wanneer je een complexe hiërarchie van objecten bespot, hoe dit soort berichten kan helpen bij het debuggen en anderszins erg nuttig kan zijn.

4. Strikt stoppen omzeilen

Laten we tot slot kijken hoe we strikte stubs kunnen omzeilen. Dit staat ook bekend als mild stoten.

Soms moeten we specifieke stubbing configureren om mild te zijn, terwijl we alle andere stubbings en bespotten handhaven om strikt stubbing te gebruiken:

@Test openbare leegte gegevenLenientdStub_whenInvokingGetThenThrowUnnnoodzakelijkStubbingException () {lenient (). When (mockList.add ("één")). ThenReturn (true); when (mockList.get (anyInt ())). thenReturn ("hallo"); assertEquals ("Lijst moet hallo bevatten", "hallo", mockList.get (1)); }

In het bovenstaande voorbeeld we gebruiken de statische methode Mockito.lenient () om het soepele stoten op de toevoegen methode van onze neplijst.

Lenige stubs omzeilen de validatieregels van "strikte stubbing". Als stubbing bijvoorbeeld mild wordt verklaard, wordt het niet gecontroleerd op mogelijke problemen met stubbing, zoals het eerder beschreven onnodige stubbing.

5. Conclusie

In dit korte artikel begonnen we met de introductie van het concept van strikt stubbing in Mockito en begrepen we de filosofie achter waarom het werd geïntroduceerd en waarom het belangrijk is.

Vervolgens hebben we gekeken naar een voorbeeld van de OnnodigStubbingException alvorens af te sluiten met een voorbeeld van hoe soepel stoten in onze tests mogelijk is.

Zoals altijd is de volledige broncode van het artikel beschikbaar op GitHub.