Mockito Strict Stubbing og The UnecessaryStubbingException

1. Oversigt

I denne hurtige vejledning lærer vi om Mockito UnødvendigtStubbingException. Denne undtagelse er en af ​​de almindelige undtagelser, som vi sandsynligvis støder på, når vi bruger forkert stubber.

Vi starter med at forklare filosofien bag streng stubbing, og hvorfor Mockito tilskynder brugen af ​​den som standard. Dernæst ser vi nøjagtigt på, hvad denne undtagelse betyder, og under hvilke omstændigheder den kan forekomme. For at afslutte ser vi et eksempel på, hvordan vi kan undertrykke denne undtagelse i vores tests.

For at lære mere om test med Mockito, se vores omfattende Mockito-serie.

2. Streng stubbing

Med version 1.x af Mockito var det muligt at konfigurere og interagere med mocks uden nogen form for begrænsning. Dette betød, at test over tid ofte blev overkomplicerede og til tider sværere at debugge.

Siden version 2. +, Mockito har introduceret nye funktioner, der skubber rammen mod "strenghed". De vigtigste mål bag dette er:

  • Registrer ubrugte stubber i testkoden
  • Reducer duplikering af testkode og unødvendig testkode
  • Fremme renere tests ved at fjerne 'død' kode
  • Hjælp med at forbedre fejlfinding og produktivitet

At følge disse principper hjælper os med at oprette renere tests ved at fjerne unødvendig testkode. De hjælper også med at undgå kopipasta-fejl samt andre udviklerovervågninger.

For at opsummere rapporterer streng stubning unødvendige stubber, registrerer stubbing af argumenter, der ikke stemmer overens, og gør vores test mere TØR (gentag ikke dig selv). Dette letter en ren og vedligeholdelig codebase.

2.1. Konfiguration af strenge stubbe

Siden Mockito 2. + bruges streng stubbing som standard, når vi initialiserer vores mocks ved hjælp af en af:

  • MockitoJUnitRunner
  • MockitoJUnit.rule ()

Mockito anbefaler kraftigt brugen af ​​et af ovenstående. Der er dog også en anden måde at muliggøre streng stubbing i vores tests, når vi ikke udnytter Mockito-reglen eller løberen:

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

Et sidste vigtigt punkt at gøre er, at i Mockito 3.0 vil alle stubbings være "strenge" og valideret som standard.

3. UnødvendigtStubbingException Eksempel

Kort sagt, en unødvendig stub er et stubmet metodeopkald, der aldrig blev realiseret under testudførelse.

Lad os se på et simpelt eksempel:

@Test offentlig ugyldighed givenUnusedStub_whenInvokingGetThenThrowUnnecessaryStubbingException () {when (mockList.add ("one")). ThenReturn (true); // dette kaldes ikke når (mockList.get (anyInt ())). derefterReturn ("hej"); assertEquals ("Listen skal indeholde hej", "hej", mockList.get (1)); }

Når vi kører denne enhedstest, registrerer Mockito den ubrugte stub og kaster en UnødvendigtStubbingException:

org.mockito.exceptions.misusing.UnnecessaryStubbingException: Unødvendige stubbings fundet. Ren og vedligeholdelig testkode kræver nul unødvendig kode. Følgende stubbings er unødvendige (klik for at navigere til relevant kodelinje): 1. -> på com.baeldung.mockito.misusing.MockitoUnecessaryStubUnitTest.givenUnusedStub_whenInvokingGetThenThrowUnnecessaryStubbingException (MockitoUnecessaryStubUnitTest.java:37) Fjern venligst unødvendig. Mere info: javadoc til UnødvendigStubbingException-klasse.

Heldigvis er det helt klart fra fejlmeddelelsen, hvad problemet er her. Vi kan også se, at undtagelsesmeddelelsen endda peger os på den nøjagtige linje, der forårsager fejlen.

Hvorfor sker dette? Nå, den første hvornår påkaldelse konfigurerer vores mock at vende tilbage rigtigt når vi kalder tilføje metode med argumentet "en". Vi påberåber dog ikke denne metode under resten af ​​enhedstestudførelsen.

Mockito fortæller os, at vores første hvornår linjen er overflødig, og måske lavede vi en fejl, når vi konfigurerede vores stubber.

Selvom dette eksempel er trivielt, er det let at forestille sig, når man spotter et komplekst hierarki af objekter, hvordan denne form for meddelelse kan hjælpe med fejlretning og ellers være meget hjælpsom.

4. Omgå streng strubning

Lad os endelig se, hvordan man omgår strenge stubbe. Dette er også kendt som mild stubning.

Nogle gange er vi nødt til at konfigurere specifik stubbing til at være mild, mens vi opretholder alle de andre stubbings og mocks til at bruge streng stubbing:

@Test offentlig ugyldighed givenLenientdStub_whenInvokingGetThenThrowUnnecessaryStubbingException () {lenient (). When (mockList.add ("one")). ThenReturn (true); når (mockList.get (anyInt ())). derefterReturn ("hej"); assertEquals ("Listen skal indeholde hej", "hej", mockList.get (1)); }

I ovenstående eksempel vi bruger den statiske metode Mockito.lenient () for at muliggøre en mild stubning på tilføje metode til vores mock-liste.

Lette stubbe omgår “strenge stubbing” -valideringsregler. For eksempel, når stubning erklæres som mild, kontrolleres det ikke for potentielle stubbeproblemer såsom den unødvendige stubning, der er beskrevet tidligere.

5. Konklusion

I denne korte artikel begyndte vi med at introducere begrebet streng stubbing i Mockito og forstod filosofien bag, hvorfor den blev introduceret, og hvorfor den er vigtig.

Dernæst så vi på et eksempel på UnødvendigtStubbingException inden du afslutter med et eksempel på, hvordan du muliggør mild stubning i vores tests.

Som altid er artiklens fulde kildekode tilgængelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found