Haladó tesztelés a Mockitoval

1.1 Mockito könyvtár

Ma a haladó teszteléssel fogunk megismerkedni. Pontosabban a Mockito könyvtárral . Ne is gondolj arra, hogy kiszállsz ebből az üzletből.

Először is, ez a könyvtár a tavaszi tesztelés szabványa . Ami tulajdonképpen a szabvány a Java háttérfejlesztő iparban.

Másodszor, teszteket kell írnod ​​a tavaszi kódodhoz . Az egyetlen módja annak, hogy megértsük, hogy az Ön által írt háttérprogram megfelelően működik, az az API metódusainak meghívása . És tesztekkel 10-szer könnyebb, mint anélkül. Majd meglátod magad.

A Mockito könyvtárat pom.xmla kóddal adhatja hozzá:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

A Mockito projekt teljes forráskódja megtalálható a GitHubon .

1.2 Objektumok kijátszása

Szóval mi ez a Mockito és miért olyan jó?

A tesztelés fejlesztése és fejlesztése során nagyon gyakran felmerült az igény, hogy valódi objektum helyett valamilyen „csonkot” csúsztassanak a kódba.

Például az adatbázissal működő kódot tesztelik, és ott változtat valamit. Jó, ha minden teszt előtt ugyanaz ennek az adatbázisnak az állapota (különben a tesztek eltérőek lesznek). És szeretném, ha az alap egyszerűbb lenne, hogy gyorsan vissza tudjam görgetni ezeket az állapotokat.

Vagy például olyan kódot tesztel, amely hasznos SMS-eket küld. A direkt levélküldéshez pedig valamilyen fizetős SMS Gateway-t használ. Jó lenne belecsúsztatni valami virtuális Gateway-t a kód tesztelésére, nehogy több száz SMS-t küldjön értetlen embereknek.

Vagy a kód más webszerverektől kér adatokat, amelyek egyszerűen nem állnak rendelkezésre a tesztszerveren. Vagy írsz egy kódot az online fizetésekhez, amelyet 50-szer kell tesztelni, és csak ezután engedni valós pénzügyi csatornákon való felhasználást.

Szerintem érted... A virtuális objektumok, vagy ahogyan csonkobjektumoknak is nevezik, nagyon hasznos dolog.

És itt jön a nehézség – a Java statikus gépelést tartalmaz. Ez azt jelenti, hogy ahhoz, hogy ReadDatabaseegy objektumra való hivatkozást egy változóhoz rendeljen hozzá egy típusú objektum helyett, az osztályt a következőtől VirtualDatabasekell örökölnie .VirtualDatabaseRealDatabase

Aztán kiderül, hogy az osztálynak van RealDatabaseegy csomó privát metódusa és változója, amelyek más valós objektumokra való hivatkozásokat tárolnak, és így nem lehet normális csonkot írni. Elméletileg jó, de a gyakorlatban zsákutca.

És itt jön a megmentés ( DynamicProxybővebben olvashatsz ), ami még a Java 5-ben jelent meg. Lehetővé teszi olyan virtuális objektumok létrehozását, amelyekre a fordítónak nincs panasza.

Az ilyen virtuális objektumokat gúnynak nevezik (a mock szóból - elrendezés). A Mockito könyvtár soha nem látott magasságba tudta emelni a munkát ezekkel a gúnyokkal. Innen egyébként a könyvtár neve.

1.3 @Bővítés megjegyzéssel

A Mockito könyvtár remekül működik a JUnit-tal, akár annak kiterjesztésének is tekinthető.

Kétféleképpen engedélyezheti a Mockito könyvtárat az egységtesztekben. Az első módszer egy speciális megjegyzés hozzáadása:

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

A második módszer az, hogy engedélyezze a munkáját a metódus meghívásával openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

Leggyakrabban az első lehetőséget látja, de néha hasznos tudni, hogy van egy második is.