Forskjellen mellom når () og doXxx () -metoder i Mockito

1. Introduksjon

Mockito er et populært Java-mocking-rammeverk. Med det er det enkelt å lage mock-objekter, konfigurere mock-oppførsel, fange metodeargumenter og verifisere interaksjoner med mocks.

Nå vil vi fokusere på å spesifisere mock atferd. Vi har to måter å gjøre det på: når (). deretterDoSomething () og doSomething (). når () syntaks.

I denne korte opplæringen vil vi se hvorfor vi har begge to.

2. når() Metode

La oss vurdere følgende Ansatt grensesnitt:

grensesnitt Ansatt {String hilsen (); ugyldig arbeid (DayOfWeek dag); }

I testene våre bruker vi en narr av dette grensesnittet. La oss si at vi vil konfigurere mock-ene hilse på() metode for å returnere strengen "Hallo". Det er greit å gjøre det ved å bruke Mockito's når() metode:

@Test ugyldig gittNonVoidMethod_callingWhen_shouldConfigureBehavior () {// gitt når (medarbeiderhilsen ()). ThenReturn ("Hei"); // når strenghilsen = ansatt. hilsen (); // deretter assertThat (hilsen, er ("Hello")); }

Hva skjer? De ansatt objektet er en hån. Når vi kaller noen av metodene, registrerer Mockito den samtalen. Med samtalen fra når() metode, vet Mockito at denne påkallingen ikke var en interaksjon av forretningslogikken. Det var en uttalelse om at vi ønsker å tildele noe oppførsel til det spotte objektet. Etter det, med en av thenXxx () metoder, spesifiserer vi forventet oppførsel.

Inntil dette punktet er det god gammel hån. På samme måte vil vi konfigurere arbeid() metode for å kaste et unntak når vi kaller det med et argument fra søndag:

@Test ugyldig givenVoidMethod_callingWhen_wontCompile () {// gitt når (medarbeider.arbeid (DayOfWeek.SUNDAY)). ThenTrow (ny IAmOnHolidayException ()); // når kjørbar workCall = () -> medarbeider.arbeid (DayOfWeek.SUNDAY); // deretter assertThrows (IAmOnHolidayException.class, workCall); }

Dessverre vil ikke denne koden kompileres, fordi i arbeid (ansatt. arbeid (...)) Ring arbeid() metoden har en tomrom retur type; derfor kan vi ikke pakke det inn i en annen metodeanrop. Betyr det at vi ikke kan spotte ugyldige metoder? Selvfølgelig kan vi det. doXxx metoder til unnsetning!

3. doXxx () Metoder

La oss se hvordan vi kan konfigurere unntakskasting med doTrow () metode:

@Test ugyldig givenVoidMethod_callingDoThrow_shouldConfigureBehavior () {// gitt doThrow (ny IAmOnHolidayException ()). Når (ansatt) .work (DayOfWeek.SUNDAY); // når kjørbar workCall = () -> medarbeider.arbeid (DayOfWeek.SUNDAY); // deretter assertThrows (IAmOnHolidayException.class, workCall); }

Denne syntaksen er litt annerledes enn den forrige: vi prøver ikke å pakke inn en tomrom metode samtale inne i en annen metodeanrop. Derfor kompilerer denne koden.

La oss se hva som nettopp skjedde. Først uttalte vi at vi ønsker å kaste et unntak. Deretter kalte vi når() metoden, og vi passerte den spotte gjenstanden. Etter det spesifiserte vi hvilken spott interaksjon atferd vi vil konfigurere.

Merk at dette ikke er det samme når() metoden vi brukte før. Vær også oppmerksom på at vi lenket den hånlige interaksjonen etter påkallingen av når(). I mellomtiden definerte vi det i parentes med den første syntaksen.

Hvorfor har vi den første når (). deretterXxx (), når den ikke er i stand til en så vanlig oppgave, som å konfigurere en tomrom påkallelse? Det har flere fordeler med doXxx (). når () syntaks.

Først, det er mer logisk for utviklere å skrive og lese utsagn som "når noe interaksjon, så gjør noe" enn "gjør noe, når noe samspill".

For det andre kan vi legge til flere atferd i samme interaksjon med kjetting. Det er fordi når() returnerer en forekomst av klassen PågåendeStubbing, som er thenXxx () metoder returnerer samme type.

På den andre siden, doXxx () metoder returnerer a Stubber eksempel, og Stubber.when (T mock) returnerer T, slik at vi kan spesifisere hva slags metodeinnkalling vi vil konfigurere. Men T er en del av søknaden vår, for eksempel Ansatt i kodebitene våre. Men T vil ikke returnere en Mockito-klasse, så vi vil ikke kunne legge til flere atferd med kjetting.

4. BDDMockito

BDDMockito bruker en alternativ syntaks til de som vi dekket. Det er ganske enkelt: i våre mock-konfigurasjoner må vi erstatte nøkkelordet “når" til "gitt”Og nøkkelordet“gjøre" til "vil“. Annet enn det, forblir koden vår den samme:

@Test ugyldig givenNonVoidMethod_callingGiven_shouldConfigureBehavior () {// gitt gitt (medarbeiderhilsen ()). WillReturn ("Hei"); // når strenghilsen = ansatt. hilsen (); // deretter assertThat (hilsen, er ("Hello")); } @Test ugyldig givenVoidMethod_callingWillThrow_shouldConfigureBehavior () {// gitt willThrow (ny IAmOnHolidayException ()). Gitt (ansatt) .work (DayOfWeek.SUNDAY); // når kjørbar workCall = () -> medarbeider.arbeid (DayOfWeek.SUNDAY); // deretter assertThrows (IAmOnHolidayException.class, workCall); }

5. Konklusjon

Vi så fordelene og ulempene med å konfigurere en mock-gjenstand når (). deretterXxx () eller doXxx (). når () vei. Vi så også hvordan disse syntaksen fungerer, og hvorfor vi har begge deler.

Som vanlig er eksemplene tilgjengelige på GitHub.


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