streamalism.org

1. Áttekintés

Ebben az oktatóanyagban megnézzük a JUnit 4 könyvtár által biztosított Szabályok funkciót.

Először a JUnit szabályok modelljének bevezetésével kezdjük, mielőtt áttekintenénk a disztribúció által biztosított legfontosabb alapszabályokat. Ezenkívül meglátjuk, hogyan írhatunk és használhatunk saját egyéni JUnit-szabályt.

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

Ne feledje, hogy az 5. JUnit használata esetén a szabályokat felváltotta az Extension modell.

2. Bevezetés a JUnit 4 szabályaiba

A JUnit 4 szabályai rugalmas mechanizmust biztosítanak a tesztek javításához egy kód futtatásával egy teszteset végrehajtása körül. Bizonyos értelemben hasonló a birtokláshoz @Előtt és @Utána kommentárok teszt osztályunkban.

Képzeljük el, hogy a tesztbeállítás során csatlakozni akartunk egy külső erőforráshoz, például egy adatbázishoz, majd a teszt befejezése után lezárjuk a kapcsolatot. Ha ezt az adatbázist több tesztben szeretnénk használni, akkor minden tesztben megkettőznénk ezt a kódot.

Egy szabály használatával mindent egy helyen elkülöníthetünk, és több tesztosztályból könnyen felhasználhatjuk a kódot.

3. A JUnit 4 szabályok használata

Tehát hogyan használhatjuk a szabályokat? A JUnit 4 szabályait az alábbi egyszerű lépésekkel használhatjuk:

• Adja hozzá a nyilvános mezőt a tesztosztályunkba, és győződjön meg arról, hogy ennek a mezőnek a típusa a org.junit.rules.TestRule felület
• Jegyezze fel a mezőt a @Szabály annotáció

A következő részben meglátjuk, hogy milyen projektfüggőségekre van szükségünk az induláshoz.

4. Maven-függőségek

Először tegyük hozzá a példákhoz szükséges projektfüggőségeket. Csak a fő JUnit 4 könyvtárra lesz szükségünk:

 junit junit 4.12 

Mint mindig, a legújabb verziót is megkapjuk a Maven Central-tól.

5. A terjesztésben megadott szabályok

Természetesen, A JUnit számos hasznos, előre definiált szabályt kínál a könyvtár részeként. Ezeket a szabályokat megtalálhatjuk a org.junit.rules csomag.

Ebben a részben néhány példát fogunk látni azok használatára.

5.1. A TemporaryFolder Szabály

Teszteléskor gyakran szükségünk van egy ideiglenes fájl vagy mappa elérésére. A fájlok létrehozásának és törlésének kezelése azonban nehézkes lehet. Használni a TemporaryFolder szabály szerint kezelhetjük a fájlok és mappák létrehozását, amelyeket törölni kell, amikor a tesztelési módszer leáll:

@Rule public TemporaryFolder tmpFolder = new TemporaryFolder (); @Test public void givenTempFolderRule_whenNewFile_thenFileIsCreated () dobja az IOException {File testFile = tmpFolder.newFile ("test-file.txt"); assertTrue ("A fájlt létre kellett volna hozni:", testFile.isFile ()); assertEquals ("A temp mappának és a tesztfájlnak meg kell egyeznie:", tmpFolder.getRoot (), testFile.getParentFile ()); }

Mint láthatjuk, először meghatározzuk a TemporaryFolder szabály tmpFolder. Ezután tesztelési módszerünk létrehozza a nevű fájlt test-file.txt az ideiglenes mappában. Ezután ellenőrizzük, hogy a fájl létrejött-e és létezik-e ott, ahol kellene. Nagyon szép és egyszerű!

A teszt befejezése után az ideiglenes mappát és fájlt törölni kell. Ez a szabály azonban nem ellenőrzi, hogy a törlés sikeres-e.

Van még néhány érdekes módszer, amelyet érdemes megemlíteni ebben az osztályban:

• új fájl()

  Ha nem adunk meg fájlnevet, akkor ez a módszer véletlenszerűen elnevezett új fájlt hoz létre.

• newFolder (String ... mappaNév)

  Rekurzívan mély ideiglenes mappák létrehozásához használhatjuk ezt a módszert.

• új mappa()

  Hasonlóképpen a új mappa() A módszer egy véletlenszerűen elnevezett új mappát hoz létre.

Érdemes megemlíteni, hogy a 4.13-as verziótól kezdve a TemporaryFolder szabály lehetővé teszi a törölt erőforrások ellenőrzését:

@Rule public TemporaryFolder mappa = TemporaryFolder.builder (). AssureDeletion (). Build ();

Ha egy erőforrást nem lehet törölni, akkor a sikertelen teszt egy AssertionError.

Végül az 5. JUnit-ben ugyanazt a funkciót érhetjük el az Temporary Directory kiterjesztés használatával.

5.2. A ExpectedException Szabály

Ahogy a neve is sugallja, használhatjuk a ExpectedException szabály annak ellenőrzésére, hogy egyes kódok várható kivételt hoznak-e:

@Rule public final ExpectedException dobott = ExpectedException.none (); @Test public void givenIllegalArgument_whenExceptionThrown_MessageAndCauseMatches () {thrown.expect (IllegalArgumentException.class); thrown.expectCause (isA (NullPointerException.class)); thrown.expectMessage ("Ez illegális"); dobja az új IllegalArgumentException ("Ez illegális", új NullPointerException ()); }

Amint a fenti példában láthatjuk, először deklaráljuk a ExpectedException szabály. Aztán tesztünk során azt állítjuk, hogy an IllegalArgumentException dobják.

E szabály használatával ellenőrizhetjük a kivétel néhány egyéb tulajdonságát is, például az üzenetet és az okot.

A JUnit kivételek tesztelésének részletes útmutatójaért tekintse meg kiváló útmutatónkat a kivétel érvényesítéséről.

5.3. A TestName Szabály

Leegyszerűsítve: TestName szabály megadja az aktuális tesztnevet egy adott vizsgálati módszeren belül:

@Rule public TestName name = új TestName (); @Test public void givenAddition_whenPrintingTestName_thenTestNameIsDisplayed () {LOG.info ("Végrehajtás: {}", név.getMethodName ()); assertEquals ("adottAddition_whenPrintingTestName_thenTestNameIsDisplayed", name.getMethodName ()); }

Ebben a triviális példában az egység teszt futtatásakor látni kell a teszt nevét a kimenetben:

INFO c.baeldung.rules.JUnitRulesUnitTest - Végrehajtás: megadottAddition_whenPrintingTestName_thenTestNameIsDisplayed

5.4. A Időtúllépés Szabály

Ebben a következő példában megnézzük a Időtúllépés szabály. Ez a szabály hasznos alternatívát kínál az időtúllépés paraméter használatához az egyes tesztjegyzeteknél.

Most nézzük meg, hogyan használhatjuk ezt a szabályt a globális időtúllépés beállításához a tesztosztályunk összes vizsgálati módszerén:

@Rule public Timeout globalTimeout = Timeout.seconds (10); @Test public void givenLongRunningTest_whenTimout_thenTestFails () dobja az InterruptedException {TimeUnit.SECONDS.sleep (20); }

A fenti triviális példában először 10 másodperces globális időtúllépést határozunk meg az összes vizsgálati módszerhez. Ezután szándékosan meghatározunk egy tesztet, amely 10 másodpercnél tovább tart.

Amikor lefuttatjuk ezt a tesztet, látnunk kell egy teszthibát:

org.junit.runners.model.TestTimedOutException: a teszt 10 másodperc múlva túllépte ...

5.5. A ErrorCollector Szabály

Legközelebb megnézzük a ErrorCollector szabály. Ez a szabály lehetővé teszi a teszt végrehajtásának folytatását az első probléma megtalálása után.

Nézzük meg, hogyan használhatjuk ezt a szabályt az összes hiba összegyűjtésére és egyszerre jelentésre, amikor a teszt befejeződik:

@Rule public final ErrorCollector errorCollector = új ErrorCollector (); @Test public void givenMultipleErrors_whenTestRuns_thenCollectorReportsErrors () {errorCollector.addError (new Throwable ("Az első dolog rosszul ment!")); errorCollector.addError (new Throwable ("Egy másik dolog rosszul ment!")); errorCollector.checkThat ("Hello World", nem (tartalmazzaString ("ERROR!"))); }

A fenti példában két hibát adunk a gyűjtőhöz. Amikor lefuttatjuk a tesztet, a végrehajtás folytatódik, de a teszt a végén kudarcot vall.

A kimenetben mindkét hibát jelenteni fogjuk:

java.lang.Hajítható: Először rosszul ment! ... java.lang. Dobható: Egy másik dolog rosszul esett!

5.6. A Igazoló Szabály

A Igazoló A szabály egy absztrakt alaposztály, amelyet akkor használhatunk, ha a tesztjeinkből további viselkedést akarunk ellenőrizni. Valójában a ErrorCollector Az utolsó szakaszban látott szabály kiterjeszti ezt az osztályt.

Most nézzünk meg egy triviális példát saját hitelesítőnk meghatározására:

private List messageLog = new ArrayList (); @Rule public Verifier verifier = new Verifier () {@Orride public void verify () {assertFalse ("Az Üzenetnapló nem üres!", MessageLog.isEmpty ()); }}; 

Itt definiálunk egy újat Igazoló és felülírja a igazolni () módszer hozzáadni néhány extra ellenőrzési logikát. Ebben az egyszerű példában egyszerűen ellenőrizzük, hogy a példánkban szereplő üzenetnapló nem üres-e.

Most, amikor lefuttatjuk az egységtesztet, és hozzáadunk egy üzenetet, látnunk kell, hogy az ellenőrzőnket alkalmazták:

@Test public void givenNewMessage_whenVerified_thenMessageLogNotEmpty () {// ... messageLog.add ("Új üzenet van!"); }

5.7. A DisableOnDebug Szabály

Előfordulhat, hogy hibakeresés közben ki akarjuk tiltani a szabályt. Például gyakran kívánatos letiltani a Időtúllépés szabály a hibakereséskor, hogy elkerüljük a teszt időzítését és a kudarcot, mielőtt még volna időnk hibát hibakeresni.

A DisableOnDebug A szabály pontosan ezt teszi, és lehetővé teszi számunkra, hogy egyes szabályokat letiltani lehessen a hibakeresés során:

@Rule public DisableOnDebug disableTimeout = new DisableOnDebug (Timeout.seconds (30));

A fenti példában láthatjuk, hogy ennek a szabálynak a használatához egyszerűen átadjuk a kivetítőnek a letiltani kívánt szabályt.

Ennek a szabálynak az a fő előnye, hogy kikapcsolhatjuk a szabályokat anélkül, hogy a hibakeresés során módosítanánk a tesztosztályainkat.

5.8. A ExternalResource Szabály

Általában integrációs tesztek írásakor érdemes egy külső erőforrást felállítanunk egy teszt előtt, és utána lebontanunk. Szerencsére a JUnit egy másik praktikus alaposztályt nyújt ehhez.

Bővíthetjük az absztrakt osztályt ExternalResource külső erőforrás, például fájl vagy adatbázis-kapcsolat létrehozása a teszt előtt. Valójában a TemporaryFolder a korábban látott szabály kiterjed ExternalResource.

Vessünk egy gyors pillantást arra, hogyan bővíthetnénk ezt az osztályt:

@Rule public final ExternalResource externalResource = new ExternalResource () {@ A védett void felülbírálása, mielőtt () Throwable {// kódot dobna egy adott külső erőforrás beállításához. }; @ A védett void felülbírálása a () után {// kód a külső erőforrás lebontásához}; };

Ebben a példában, amikor definiálunk egy külső erőforrást, egyszerűen felül kell írnunk a előtt() módszer és utána() módszer a külső erőforrásunk felállítása és lebontása érdekében.

6. Osztályszabályok alkalmazása

Mindeddig az általunk megvizsgált példák egyetlen teszteset-módszerekre vonatkoztak. Előfordulhat azonban, hogy a tesztosztály szintjén érdemes alkalmazni egy szabályt. Ezt a @ClassRule annotáció.

Ez a feljegyzés nagyon hasonlóan működik @Szabály de egy egész teszt köré szab egy szabályt - a fő különbség az, hogy az osztályszabályunkhoz használt mezőnek statikusnak kell lennie:

@ClassRule public static TemporaryFolder globalFolder = new TemporaryFolder ();

7. Egyéni JUnit-szabály meghatározása

Mint láttuk, a JUnit 4 számos hasznos szabályt tartalmaz a dobozból. Természetesen meghatározhatjuk saját szokásainkat. Egyéni szabály megírásához végre kell hajtanunk a TestRule felület.

Vessen egy pillantást az egyéni tesztmódszer névnaplózó szabályának meghatározására:

public class TestMethodNameLogger végrehajtja a TestRule {private static final Logger LOG = LoggerFactory.getLogger (TestMethodNameLogger.class); @ Nyilvános nyilatkozat felülbírálása érvényes (Nyilatkozati alap, Leírás leírása) {logInfo ("Teszt előtt", leírás); próbáld meg {return new Statement () {@Orride public void assessment () throws Throwable {base.evaluate (); }}; } végül {logInfo ("Teszt után", leírás); }} private void logInfo (Karakterlánc msg, Leírás leírása) {LOG.info (msg + description.getMethodName ()); }}

Mint láthatjuk, a TestRule felület tartalmaz egy nevezett metódust alkalmazni (nyilatkozat, leírás) hogy felül kell írnunk egy példányt Nyilatkozat. A nyilatkozat a JUnit futás közbeni tesztjeinket reprezentálja. Amikor felhívjuk a értékel () módszerrel, ez végrehajtja a tesztünket.

Ebben a példában naplózunk egy előtte és utána üzenetet, és belefoglaljuk a Leírás kifogásolja az egyedi teszt metódusnevét.

8. Szabályláncok használata

Ebben az utolsó szakaszban megvizsgáljuk, hogyan rendelhetünk meg több tesztszabályt a RuleChain szabály:

@Rule public RuleChain chain = RuleChain.outerRule (új MessageLogger ("Első szabály")) .around (új MessageLogger ("Második szabály")) .around (új MessageLogger ("Harmadik szabály"));

A fenti példában három szabályból álló láncot hozunk létre, amely egyszerűen kinyomtatja a mindegyiknek továbbított üzenetet MessageLogger konstruktőr.

Amikor lefuttatjuk a tesztünket, meglátjuk, hogyan alkalmazzák a láncot sorrendben:

Indítás: Első szabály Indítás: Második szabály Indítás: Harmadik szabály kész: Harmadik szabály kész: Második szabály kész: Első szabály

9. Következtetés

Összefoglalva, ebben az oktatóanyagban részletesen feltártuk a JUnit 4 szabályait.

Először azzal kezdtük, hogy elmagyaráztuk, melyek a szabályok, és hogyan tudjuk felhasználni őket. Ezután alaposan megvizsgáltuk azokat a szabályokat, amelyek a JUnit disztribúció részeként jönnek létre.

Végül megvizsgáltuk, hogyan definiálhatjuk saját egyéni szabályunkat és hogyan kapcsolhatjuk össze a szabályokat.

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