A Java kód segítségével JUnit
Angol változata ezt a cikket megtalálja itt.
A tesztelés nem mindig szórakoztató és érdekes. Ez a folyamat általában elég hosszú, és néha tele robotolás. Úgy tűnik, csak a közelmúltban a programozók használják a szabványos kimenetre, vagy hibakereső tesztelni java osztályokat.
Ebben a cikkben fogom leírni a könyvtár JUnit 4, ami nagyban leegyszerűsíti és automatizálja a folyamatot írás tesztek.
Annak bizonyítására, a fő jellemzői a JUnit keretrendszer levelet primitív osztály a Java, és kigúnyolják. Ennek az osztálynak két módon - a megállapítás faktoros nem negatív egész szám, és az összeg a két szám. Továbbá, abban az esetben ez lesz az eljárás hívások számláló.
Most írjuk Unit tesztek. Ehhez hozzon létre egy osztályt, számos vizsgálati módszerek. Természetesen, az osztály tartalmazhat hagyományos segédanyagokat módszerekkel. Annak tesztelésére futó tudja határozni, hogy ki kicsoda, tesztelési módszereket kell jelölni anntoatsiey @Test.
Összefoglalva, az ilyen paraméterek lehet feltüntetni:
- várható -, amelyek arra utalnak kivételt fog dobni a módszerrel (lásd az alábbi példát).
- timeout - meddig ezredmásodperc megállítani a vizsgálat végrehajtását, és számít, hogy sikertelen.
Ha azt szeretnénk, hogy meghatározzák, hogy egy adott vizsgálati neobhdimo hiányzik a jel azt @Ignore kommentár. Bár akkor egyszerűen Kommentár törléséhez @Test.
Előfordul, hogy annak érdekében, hogy végre minden teszt forgatókönyv igényel némi összefüggésben például előre létrehozott példányok az osztályok. És miután annak szükségességét, hogy engedje el a fenntartott források. Ebben az esetben meg kell anntoatsii @Before és @After. Módszer jelölt @Before fog futni, mielőtt minden vizsgálat esetében, és az eljárás jelölt @After - miután minden vizsgálat esetében.
Ha az inicializálás és felszabadulását forrásokat kell tenni csak egyszer - előtt és után az összes vizsgálat - majd egy pár jegyzetekből és @BeforeClass @AfterClass.
És itt van a vizsgálati osztály néhány vizsgálati esetek:
Vizsgálati módszer a helyes hívások hívások számláló. faktoriális eljárás ellenőrzi az érvényességét a faktoriális valamilyen szabványos értékek. factorialNegative eljárás ellenőrzi, hogy a negatív értékek fogják dobni fakotriala IllegalArgumentException. todo módszer nem veszi figyelembe. Próbálja meg eltávolítani a kommentár @Ignore, ha kísérletezik kódot.
assertTrue módszer azt vizsgálja, hogy a kifejezés értéke igaz. Néhány más módszereket, amelyek hasznosak lehetnek:
- assertEquals - várt eredmény és az eredmény ugyanaz;
- assertNull - az eredmény a kifejezés null;
- assertNotNull - az eredmény a kifejezés nem nulla;
- assertSame - a várt és a kapott tárgyakat egy és ugyanaz a tárgya.
- A sikertelen - AssertionError eljárás kivételt dob - add bárhova nem éri el a végrehajtását a program.
A modern világban, IDE képesek megtalálni és csak a teszteket a projektben. De mi van, ha azt szeretnénk, hogy futtatni őket kézzel a kódot. Használhatja Runner'om. Vannak szöveg - junit.textui.TestRunner, grafikai változat - junit.swingui.TestRunner, junit.awtui.TestRunner.
De egy kicsit modernebb módszer - használata ebben az osztályban JUnitCore. Add az alábbi módszert a fő osztály MathFuncTest:
És az eredmény:
A korábbi verziók JUnit vizsgálati osztály írásához szükséges volt, hogy hozzon létre egy utód junit.framework.TestCase. Aztán meg kell határozni egy kivitelező, hogy úgy, mint a paraméter karakterlánc - a módszer neve is -, és adja meg, hogy a szülő osztályban. Minden vizsgálati módszert kellett kezdeni a tesztet előtagot. Inicializálni és engedje el a felhasznált források módszerek felépítése és bontása. Röviden horror. De most minden egyszerű, igen.
Kérjük, ismertesse a helyzetet. Mit jelent a JUnit? Például vonalak
függetlenül attól, hogy erőltetett, a vizsgálati tervben? Végtére is, amikor a hibakeresés módszer, még mindig pontosságát ellenőrizze munkáját. Tehát mi az értelme ennek a cikknek? Az a benyomás mesterkéltsége a helyzetet.
Tényleg meg akarom érteni. Köszi előre,
Minden vizsgálatot a végén, hogy komolytalan, meggondolatlan tesztek nem akart, és hogy fogják tesztelni - a nagy kérdés ...
Debug: különböző lehet, minden attól függ, az alkalmazás - vannak esetek, amikor nem manuális hibakeresés nem tud semmilyen módon (amely összegyűjti tesztelők csapat), de vannak esetek, amikor az egyszerű dolgokat lehet ellenőrizni a szakaszában az alkalmazás szerelés - erre, és hozzon létre JUnit-tesztek. El kell fogadnia, hogy ez sokkal kellemesebb, ha egy személy végez munkát darab vas, de még mindig gyors, és fordításkor.
Ez a példa csak egy osztályba, de a valóságban sokkal nagyobb lehet (és a függőségek között is), ezért a hibák esélye növekszik ...
Nagyon ritkán előfordul, hogy az osztály meg van írva egyszer és mindenkorra, SDK, és rendszeresen frissít. Innen és szükség van az automatikus teszteket.