streamalism.org

1. Introduktion

Mockito er en populær Java-mocking-ramme. Med det er det nemt at oprette mock-objekter, konfigurere mock-opførsel, fange metodeargumenter og kontrollere interaktioner med mocks.

Nu vil vi fokusere på at specificere mock-opførsel. Vi har to måder at gøre det på: når (). derefterDoSomething () og doSomething (). når () syntaks.

I denne korte vejledning ser vi, hvorfor vi har dem begge.

2. hvornår() Metode

Lad os overveje følgende Medarbejder grænseflade:

interface Medarbejder {String hilsen (); ugyldigt arbejde (DayOfWeek dag); }

I vores test bruger vi en mock af denne grænseflade. Lad os sige, at vi vil konfigurere mockens hilse() metode til at returnere strengen "Hej". Det er ligetil at gøre det ved hjælp af Mockito's hvornår() metode:

@Test ugyldigt givenNonVoidMethod_callingWhen_shouldConfigureBehavior () {// givet når (medarbejderhilsen ()). DerefterReturn ("Hej"); // når strenghilsen = medarbejderhilsen (); // derefter assertThat (hilsen er ("Hej")); }

Hvad der sker? Det medarbejder objekt er en hån. Når vi kalder en af ​​dens metoder, registrerer Mockito det opkald. Med opkald fra hvornår() metode, ved Mockito, at denne påkaldelse ikke var en interaktion med forretningslogikken. Det var en erklæring om, at vi ønsker at tildele noget adfærd til det mock-objekt. Derefter med en af derefterXxx () metoder, specificerer vi den forventede adfærd.

Indtil dette punkt er det god gammel hån. Ligeledes ønsker vi at konfigurere arbejde() metode til at kaste en undtagelse, når vi kalder det med et argument fra søndag:

@Test ugyldigt givenVoidMethod_callingWhen_wontCompile () {// givet når (medarbejder.arbejde (DayOfWeek.SUNDAY)). ThenThrow (ny IAmOnHolidayException ()); // når Executable workCall = () -> medarbejder.work (DayOfWeek.SUNDAY); // derefter assertThrows (IAmOnHolidayException.class, workCall); }

Desværre kompilerer denne kode ikke, fordi i arbejde (medarbejder. arbejde (…)) opkald, den arbejde() metoden har en ugyldig returtype derfor kan vi ikke pakke det ind i en anden metodeopkald. Betyder det, at vi ikke kan spotte ugyldige metoder? Selvfølgelig kan vi det. doXxx metoder til undsætning!

3. doXxx () Metoder

Lad os se, hvordan vi kan konfigurere undtagelseskastningen med doTrow () metode:

@Test ugyldigt givenVoidMethod_callingDoThrow_shouldConfigureBehavior () {// givet doThrow (ny IAmOnHolidayException ()). Når (medarbejder) .work (DayOfWeek.SUNDAY); // når Executable workCall = () -> medarbejder.work (DayOfWeek.SUNDAY); // derefter assertThrows (IAmOnHolidayException.class, workCall); }

Denne syntaks er lidt anderledes end den forrige: vi prøver ikke at pakke en ugyldig metodeopkald inde i en anden metodeopkald. Derfor kompileres denne kode.

Lad os se, hvad der lige er sket. For det første sagde vi, at vi ønsker at kaste en undtagelse. Dernæst kaldte vi hvornår() metode, og vi passerede det spotte objekt. Derefter specificerede vi, hvilken mock-interaktion adfærd vi vil konfigurere.

Bemærk, at dette ikke er det samme hvornår() metode, vi brugte før. Bemærk også, at vi lænket den spotte interaktion efter påkaldelsen af hvornår(). I mellemtiden definerede vi det inden for parenteserne med den første syntaks.

Hvorfor har vi den første når (). derefterXxx (), når det ikke er i stand til en sådan fælles opgave, som at konfigurere en ugyldig påkaldelse? Det har flere fordele for doXxx (). når () syntaks.

Først, det er mere logisk for udviklere at skrive og læse udsagn som "når noget interaktion, så gør noget" end "gør noget, når noget interaktion".

For det andet kan vi tilføje flere adfærd til den samme interaktion med kæde. Det er fordi hvornår() returnerer en forekomst af klassen Løbende stubning, hvilket er derefterXxx () metoder returnerer samme type.

På den anden side, doXxx () metoder returnerer a Stubber eksempel og Stubber. Når (T mock) vender tilbage T, så vi kan specificere, hvilken type metodeindkaldelse vi vil konfigurere. Men T er en del af vores ansøgning, for eksempel Medarbejder i vores kodestykker. Men T returnerer ikke en Mockito-klasse, så vi kan ikke tilføje flere adfærd med kæde.

4. BDDMockito

BDDMockito bruger en alternativ syntaks til dem, som vi dækkede. Det er ret simpelt: I vores mock-konfigurationer er vi nødt til at erstatte nøgleordet “hvornår" til "givet”Og nøgleordet“gør" til "vilje“. Bortset fra det forbliver vores kode den samme:

@Test ugyldigt givenNonVoidMethod_callingGiven_shouldConfigureBehavior () {// given given (employee.greet ()). WillReturn ("Hello"); // når strenghilsen = medarbejderhilsen (); // derefter assertThat (hilsen er ("Hej")); } @Test ugyldigt givenVoidMethod_callingWillThrow_shouldConfigureBehavior () {// given willThrow (new IAmOnHolidayException ()). Given (medarbejder) .work (DayOfWeek.SUNDAY); // når Executable workCall = () -> medarbejder.work (DayOfWeek.SUNDAY); // derefter assertThrows (IAmOnHolidayException.class, workCall); }

5. Konklusion

Vi så fordelene og ulemperne ved at konfigurere et mock-objekt når (). derefterXxx () eller den doXxx (). når () vej. Vi så også, hvordan disse syntakser fungerer, og hvorfor vi har begge dele.

Som sædvanligt er eksemplerne tilgængelige på GitHub.