streamalism.org

1. Áttekintés

Ebben a gyors bemutatóban megismerhetjük a Mockitót FeleslegesStubbingException. Ez a kivétel az egyik leggyakoribb kivétel, amellyel valószínűleg találkozunk, ha a csonkokat helytelenül használjuk.

Kezdjük azzal, hogy elmagyarázzuk a szigorú csökönyösség filozófiáját és azt, hogy miért ösztönzi a Mockito alapértelmezés szerint a használatát. Ezután megvizsgáljuk, hogy pontosan mit jelent ez a kivétel, és milyen körülmények között fordulhat elő. Befejezésül látni fogunk egy példát arra, hogyan lehet ezt a kivételt elnyomni tesztjeink során.

Ha többet szeretne megtudni a Mockito teszteléséről, tekintse meg átfogó Mockito sorozatunkat.

2. Szigorú szúrás

A Mockito 1.x verziójával bármilyen korlátozás nélkül lehetett konfigurálni és interakcióba lépni azokkal. Ez azt jelentette, hogy az idő múlásával a tesztek gyakran túlbonyolultak és időnként nehezebben debugálhatók.

A 2. + verzió óta A Mockito olyan új funkciókat vezetett be, amelyek a „szigorúság” felé mozdítják el a keretet. A fő célok a következők:

• A fel nem használt csonkok észlelése a tesztkódban
• Csökkentse a tesztkód duplikációját és a szükséges tesztkódot
• Támogassa a tisztább teszteket a „halott” kód eltávolításával
• Javíthatja a hibakereshetőséget és a termelékenységet

Ezen elvek betartása segít tisztább tesztek létrehozásában a felesleges tesztkódok kiküszöbölésével. Ezenkívül segítenek elkerülni a másolás-beillesztés hibákat, valamint a fejlesztők egyéb hibáit.

Összefoglalva, a szigorúan elgondolkodtató felesleges jelentésekről számol be, észleli a pergő érvek eltérését, és tesztjeinket SZÁRAZABBAN (Ne ismételje meg). Ez megkönnyíti a tiszta és karbantartható kódbázist.

2.1. Szigorú csonkok konfigurálása

A Mockito 2. + óta alapértelmezés szerint szigorú csípést alkalmaznak, amikor inicializálják a gúnyainkat az alábbiak egyikével:

• MockitoJUnitRunner
• MockitoJUnit.rule ()

Mockito határozottan javasolja a fentiek bármelyikének alkalmazását. Van azonban egy másik módszer is a szigorú csökönyösítés engedélyezésére tesztjeink során, amikor nem a Mockito-szabályt vagy a futót használjuk:

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

Utolsó fontos megemlítendő, hogy a Mockito 3.0-ban az összes csonk "szigorú" lesz és alapértelmezés szerint érvényes lesz.

3. FeleslegesStubbingException Példa

Egyszerűen fogalmazva: a felesleges csonk egy elcsépelt metódushívás, amely soha nem valósult meg a teszt végrehajtása során.

Vessünk egy pillantást egy egyszerű példára:

@Test public void givenUnusedStub_whenInvokingGetThenThrowUnnecessaryStubbingException () {when (mockList.add ("one")). ThenReturn (true); // ezt nem hívják meg, amikor (mockList.get (anyInt ())). thenReturn ("hello"); assertEquals ("A listának tartalmaznia kell hello", "hello", mockList.get (1)); }

Amikor lefuttatjuk ezt az egységtesztet, a Mockito észleli a fel nem használt csonkot, és dob egy FeleslegesStubbingException:

org.mockito.exceptions.misusing.UnnecessaryStubbingException: Felesleges csonkokat észleltünk. A tiszta és karbantartható tesztkódnak nulla szükségtelen kódra van szüksége. A következő csonkolások feleslegesek (kattintson a megfelelő kódsorra történő navigáláshoz): 1. -> a com.baeldung.mockito.misusing.MockitoUnecessaryStubUnitTest.givenUnusedStub_whenInvokingGetThenThrowUnnecessaryStubbingException (MockitoUnecessaryStubUbientient Please use use 'remove' remove 'eltávolítás kérjük, távolítsa el. További információ: javadoc for UnnecessaryStubbingException osztály.

Szerencsére a hibaüzenetből egyértelműen kiderül, mi a probléma itt. Láthatjuk azt is, hogy a kivétel üzenet még a hibát okozó pontos vonalra is mutat.

Miért történik ez? Nos, az első mikor Az invokáció visszaállítja az álunkat igaz amikor felhívjuk a hozzá módszer az érveléssel "egy". Ezután azonban nem használjuk ezt a módszert az egységteszt többi végrehajtása során.

Mockito azt mondja nekünk, hogy az első mikor vonal felesleges, és talán hibát vétettünk a csonkjaink konfigurálásakor.

Bár ez a példa triviális, az objektumok összetett hierarchiáját csúfolva könnyen elképzelhető, hogy ez a fajta üzenet hogyan segítheti a hibakeresést és különben nagyon hasznos lehet.

4. A szigorú szúrás megkerülése

Végül nézzük meg, hogyan lehet megkerülni a szigorú csonkokat. Ezt más néven engedékeny csöppségnek is nevezik.

Néha úgy kell beállítanunk a konkrét csonkokat, hogy engedékenyek legyenek, miközben az összes többi csonkot és gúnyt fenntartjuk a szigorú csöppség alkalmazásához:

@Test public void givenLenientdStub_whenInvokingGetThenThrowUnnecessaryStubbingException () {engedékeny (). Mikor (mockList.add ("egy")). ThenReturn (true); mikor (mockList.get (anyInt ())). thenReturn ("hello"); assertEquals ("A listának tartalmaznia kell hello", "hello", mockList.get (1)); }

A fenti példában a statikus módszert alkalmazzuk Mockito.lenient () hogy lehetővé tegye a hozzá próbalistánk módszere.

Az engedékeny csonkok megkerülik a „szigorú csökönyös” érvényesítési szabályokat. Például, ha a csonkolást engedékenynek nyilvánítják, akkor azt nem ellenőrzik potenciális csonkolási problémákra, mint például a korábban leírt felesleges csípésre.

5. Következtetés

Ebben a rövid cikkben azzal kezdtük, hogy bevezettük a szigorú csökönyösség fogalmát Mockitóban, és megértettük azt a filozófiát, amely mögött miért vezették be és miért fontos.

Ezután megnéztük a FeleslegesStubbingException mielőtt befejeznék egy példát arra, hogyan lehet engedélyezni az engedékeny elcsépelést tesztjeink során.

Mint mindig, a cikk teljes forráskódja elérhető a GitHubon.