A JWebUnit telepítése más osztálykönyvtárakéhoz hasonlóan történik. A keretrendszer használatához szükséges JAR fájlok számára létrehoztam egy testlib nevű könyvtárat a webprojekten belül. Ez azért került külön a szokásos lib könyvtártól, mert így a csak teszteléshez használt osztálykönyvtárak nem kerülnek bele az ant által generált WAR fájlba (amit a webkonténer futtat). A tesztek futtatása elvégeztethető a JUnittal, amely alapértelmezetten része a Netbeansnek.
A tesztek kétféleképpen is megírhatóak: a JUnit tesztek származtathatóak a JWebUnit WebTestCase osztályából. Ekkor az ősosztály metódusait kell hívni. Másrészt a hívások delegálásra is lehetőség van. Előbbi nálam rejtélyes NullPointerException‑nel leállt, utóbbi viszont működött. A 26. ábrán látható egy egyszerű teszteset, amely az info.html elérhetőségét vizsgálja, valamint azt, hogy az oldalon jelen van-e az „Index of” kifejezés.
import junit.framework.TestCase; import net.sourceforge.jwebunit.junit.WebTester; public class ExampleWebTestCase extends TestCase { private WebTester tester; public ExampleWebTestCase(String name) { super(name); tester = new WebTester(); tester.getTestContext().setBaseUrl("http://..."); } public void testInfoPage() { tester.beginAt("/info.html"); tester.assertTextPresent("Index of"); } }
26. ábra: Az info.html elérhetőségét vizsgáló JWebUnit teszt
A keretrendszer előnyeként hozható fel egyszerű programozhatósága, jó együttműködése a JSF által generált HTML oldalakkal, valamint egyszerű integrálhatósága a Netbeans JUnit tesztjeivel. Megemlítendő, hogy a teszteléshez szükséges az alkalmazás telepítése (deploy) az alkalmazásszerverre, illetve a keretrendszer nem a szokásos Firefox vagy Internet Explorer motort használja a tesztelésre, ami miatt esetlegesen adódhatnak különbségek a teszteset eredménye és a felhasználó által tapasztalt élmény között. Hátrányként említhető, hogy a bonyolultabb teszteket körülményes és viszonylag lassú kézzel összerakni, valamint a későbbiekben nehezen áttekinthetőek.
A tesztesetek függetlenségét úgy oldottam meg, hogy minden teszthez futásidőben új felhasználót regisztrálok, ezzel elkülönítve őket. Ezen kívül megoldható lenne EJB hívásokkal is a takarítás, vagy az adatbázis „kézi” törlésével (magából a tesztkódból; tearDown és setUp metódusok), de ezek sem garantálnák száz százalékosan, hogy minden memóriában tárolt adattól megszabadulunk. Az igazi megoldást az alkalmazás újratelepítése jelentené (redeploy), de ez nem járna annyi előnnyel, hogy megérje azt az időtöbbletet, amennyivel tovább futnának így a tesztek.
A következő lista tartalmaz néhány érdekesebb assert metódust ([39]). Ezekkel a weblap tartalmára tett feltételezések adhatóak meg, amelyek nem teljesülésekor a teszt meghiúsul.
Néhány példa a HtmlUnit plugint vezérlő metódusokra:
Legutóbbi hozzászólások
9 év 12 hét
10 év 1 hét
10 év 5 hét
10 év 23 hét
11 év 25 hét
11 év 30 hét
11 év 30 hét
11 év 31 hét
11 év 42 hét
12 év 12 hét