streamalism.org

1. Bemutatkozás

A Mockito egy népszerű Java gúnyos keretrendszer. Ezzel egyszerű gúnyobjektumokat létrehozni, gúnyos viselkedést konfigurálni, metódus-argumentumokat elfogni és ellenőrizni a gúnyokkal való kölcsönhatásokat.

Most a gúnyos viselkedés meghatározására fogunk összpontosítani. Ennek kétféle módja van: a mikor (). akkor DoSomething () és a doSomething (). mikor () szintaxis.

Ebben a rövid bemutatóban meglátjuk, miért van mindkettő.

2. mikor() Módszer

Vegyük fontolóra a következőket Munkavállaló felület:

felület Alkalmazott {String köszönés (); érvénytelen munka (DayOfWeek nap); }

Tesztjeink során ennek az interfésznek a modelljét használjuk. Tegyük fel, hogy be akarjuk állítani az álokat üdvözöl() metódus a karakterlánc visszaadásához "Helló". Egyszerű ezt megtenni a Mockito's használatával mikor() módszer:

@Test void givenNonVoidMethod_callingWhen_shouldConfigureBehavior () {// adott mikor (alkalmazott.greet ()). ThenReturn ("Hello"); // amikor String üdvözlet = alkalmazott.greet (); // majd assertThat (üdvözlet, van ("Hello")); }

Mi történik? A munkavállaló tárgy egy gúny. Amikor bármelyik módszerét meghívjuk, a Mockito regisztrálja ezt a hívást. A. Hívásával mikor() módszerrel, Mockito tudja, hogy ez az invokáció nem az üzleti logika kölcsönhatása volt. Kijelentés volt, hogy valamilyen viselkedést szeretnénk rendelni az álobjektumhoz. Ezt követően az egyik akkorXxx () módszerekkel meghatározzuk a várható viselkedést.

Addig a régi jó gúny. Hasonlóképpen szeretnénk konfigurálni a munka() módszer a kivétel elvetésére, amikor vasárnapi érvvel hívjuk:

@Test void givenVoidMethod_callingWhen_wontCompile () {// adott mikor (alkalmazott.munka (DayOfWeek.SUNDAY)). ThenThrow (új IAmOnHolidayException ()); // amikor végrehajtható workCall = () -> alkalmazott.munka (DayOfWeek.SUNDAY); // majd assertThrows (IAmOnHolidayException.class, workCall); }

Sajnos ez a kód nem áll össze, mert a munka (alkalmazott.munka (…)) hívja a munka() módszer rendelkezik a üres visszatérési típus; ezért nem tudjuk becsomagolni egy másik metódushívásba. Ez azt jelenti, hogy nem csúfolhatjuk az érvénytelen módszereket? Természetesen megtehetjük. doXxx módszerek a megmentéshez!

3. doXxx () Mód

Nézzük meg, hogyan konfigurálhatjuk a kivétel dobását a doThrow () módszer:

@Test void givenVoidMethod_callingDoThrow_shouldConfigureBehavior () {// adott doThrow (új IAmOnHolidayException ()). Mikor (alkalmazott) .work (DayOfWeek.SUNDAY); // amikor végrehajtható workCall = () -> alkalmazott.munka (DayOfWeek.SUNDAY); // majd assertThrows (IAmOnHolidayException.class, workCall); }

Ez a szintaxis kissé eltér az előzőtől: nem próbálunk a-t becsomagolni üres metódushívás egy másik metódushíváson belül. Ezért ez a kód összeáll.

Lássuk, mi történt éppen. Először kijelentettük, hogy kivételt akarunk vetni. Ezután felhívtuk a mikor() módszerrel, és elhaladtunk az ál objektum mellett. Ezt követően meghatároztuk, hogy melyik interakció viselkedését akarjuk konfigurálni.

Vegye figyelembe, hogy ez nem ugyanaz mikor() módszer, amelyet korábban használtunk. Ezenkívül vegye figyelembe, hogy a megidéző ​​interakciót a mikor(). Közben meghatároztuk a zárójelben belül az első szintaxissal.

Miért van nálunk az első mikor (). akkorXxx (), amikor nem képes olyan gyakori feladatra, mint a üres behívás? Számos előnye van a doXxx (). mikor () szintaxis.

Első, logikusabb, ha a fejlesztők olyan kijelentéseket írnak és olvasnak, mint „amikor valamilyen interakció, akkor csinálj valamit”, mint „csinálj valamit, amikor valamilyen interakció”.

Másodszor, több viselkedést is hozzáadhatunk ugyanahhoz a kölcsönhatáshoz a láncolással. Azért mert mikor() az osztály egy példányát adja vissza Folyamatos dörzsölés, ami akkorXxx () módszerek ugyanazt a típust adják vissza.

Másrészről, doXxx () módszerek adják vissza a Stubber például, és Stubber.when (T gúny) visszatér T, így megadhatjuk, hogy milyen metódushívást szeretnénk konfigurálni. De T például az alkalmazásunk része, Munkavállaló kódrészleteinkben. De T nem ad vissza Mockito osztályt, ezért nem tudunk több viselkedést hozzáadni láncolással.

4. BDDMockito

A BDDMockito alternatív szintaxist használ az általunk lefedettekkel szemben. Ez nagyon egyszerű: az álkonfigurációinkban ki kell cserélnünk a „mikor" nak nek "adott”És a„csinálni" nak nek "akarat“. Ezen kívül a kódunk ugyanaz marad:

@Test void givenNonVoidMethod_callingGiven_shouldConfigureBehavior () {// megadott megadott (worker.greet ()). WillReturn ("Hello"); // amikor String üdvözlet = alkalmazott.greet (); // majd assertThat (üdvözlet, van ("Hello")); } @Test void givenVoidMethod_callingWillThrow_shouldConfigureBehavior () {// megadott willThrow (új IAmOnHolidayException ()). Megadott (alkalmazott) .work (DayOfWeek.SUNDAY); // amikor végrehajtható workCall = () -> alkalmazott.munka (DayOfWeek.SUNDAY); // majd assertThrows (IAmOnHolidayException.class, workCall); }

5. Következtetés

Láttuk az ál-objektum konfigurálásának előnyeit és hátrányait mikor (). akkorXxx () vagy a doXxx (). mikor () út. Láttuk, hogyan működnek ezek a szintaxisok, és miért van mindkettőnk.

Szokás szerint a példák elérhetők a GitHub oldalon.