Cactus – open source testovací framework

Cactus ako testovací framework je určený pre overovanie server-side Java kódu. Konkrétne je určený pre testovanie servletov, servlet filtrov a stránok JSP. Cactus sa využíva ako jeden z nástrojov extrémneho programovania, pretože umožňuje rýchlo, pomerne jednoducho a efektívne riadiť overovanie funkčnosti softvéru vo fáze vývoja.

Predstavenie

Nástroj Cactus je rozšírením iného testovacieho nástroja, JUnit, ktorý je základným nástrojom extrémneho programovania v súvislosti s testovaním kódu. Cactus je tvorený troma základnými triedami odvodenými z junit.framework.TestCase. Sú to tieto triedy:

• org.apache.cactus.ServletTestCase
• org.apache.cactus.JspTestCase
• org.apache.cactus.FilterTestCase

Všimnite si, že každá trieda zastupuje určitý testovací okruh (servlet, JSP alebo servlet filter). Každý z týchto okruhov obsahuje špecifickú množinu funkcií a ich možností. Postupne sa nimi budeme zaoberať. Určitou črtou frameworku Cactus je, že pri testovaní využíva nie len stranu servera, ale aj stranu klienta. Toto je podstatný rozdiel oproti iným testovacím nástrojom, ktoré často využívajú na testovanie len stranu servera.

Pri používaní Cactusu si musíte vytvoriť vlastnú triedu odvodenú od niektorej z vyššie uvedených. Cactus potom vytvorí a používa dve inštancie vašej triedy. Jedna z nich beží na klientovom JVM a druhá beží v rámci JVM servlet kontajnera. Aké to má výhody? Inštancia na strane klienta môže do objektu request vkladať ďalšie parametre, ako aj manipulovať s HTTP hlavičkou. Inštancia na strane servera potom vykonáva jednotlivé testovacie metódy a aplikačnú logiku. Následne sa klientovi vytvorí a pošle odpoveď, a ten si môže overiť, či dostal očakávanú informáciu.

Ak dobre nepoznáte princípy fungovania technológie Java Servlets a JavaServer Pages a chceli by ste si niečo o nich prečítať na stránkach Interval.cz, potom vás odkazujem na dve série článkov o týchto technológiách, konkrétne Java Servlets a JavaServer Pages pro všechny.

Vráťme sa však ku Cactusu. Mali by ste vedieť, že všetky testy, ktoré vytvoríte, treba najprv nasadiť na server ako web aplikácie (*.war súbor), obsahujúce validný web.xml súbor, samotné Cactus testy a triedy potrebné na beh týchto testov. Je to nutné práve z toho dôvodu, že testy bežia na obidvoch stranách „barikády“.

Každý testovací okruh obsahuje takzvané implicitné objekty. Tieto objekty sú dostupné len v rámci konkrétnej testovacej inštancie bežiacej na servery. Používajú sa na uchovávanie a obsluhu informácií, ktorých existencia sa predpokladá ešte pred vykonaním akejkoľvek testovacej metódy. Napríklad implicitný objekt config sa používa na nastavenie inicializačných parametrov objektov. Nasleduje prehľad jednotlivých implicitných objektov:

• org.apache.cactus.ServletTestCase
  –  HttpServletRequestWrapper request
  –  HttpServletResponse response
  –  HttpSession session
  –  ServletConfigWrapper config
• org.apache.cactus.JspTestCase
  –  PageContextWrapper pageContext
  –  JspWriter out
• org.apache.cactus.FilterTestCase
  –  HttpServletRequestWrapper request
  –  HttpServletResponse response
  –  FilterConfigWrapper config
  –  FilterChain filterChain

Ako som povedal, Cactus vykonáva testy u klienta aj na servery, čo znamená vytvorenie dvoch inštancií vášho testu. Pre lepšiu predstavu si prezrite nasledujúci obrázok:

Ako prvé JUnit test runner bežiaci na klientovom JVM vytvorí inštanciu vášho testu, v našom prípade je to MyTestCase. Redirektor proxy bežiaci na servery vytvorí druhú inštanciu testu a zároveň je zodpovedný za jeho riadenie. Prejdime si jednotlivé kroky:

1. JUnit test runner potom, čo vytvorí inštanciu vášho testu, zavolá metódu runTest(). Pre každú testXXX() metódu vyhľadá Cactus nepovinnú metódu beginXXX(WebRequest). Napríklad ak testovacia metóda sa volá testGetCustomerName(), potom Cactus hľadá na strane klienta metódu s názvom beginGetCustomerName(WebRequest). Metóda beginXXX(WebRequest) počíta aj s rôznymi HTTP parametrami a hlavičkami, ktoré môžu byť pridané k objektu WebRequest.
2. So serverom je nadviazané klasické HTTP spojenie. Cactus odošle na server prostredníctvom tohto spojenia WebRequest.
3. Redirektor proxy bežiaci na servery prevezme kontrolu, vytvorí inštanciu vášho testu a nastaví príslušné implicitné objekty. Iba potom, čo nová inštancia je úspešne vytvorená, sú implicitné objekty plne k dispozícii. Tieto objekty sú však dostupné len na strane servera, pokus o prístup k nim zo strany klienta vedie k NullPointerException.
4. Redirektor zavolá metódu setUp() a následne testXXX().
5. Metóda testXXX() musí vytvoriť novú inštanciu vášho servletu a metód potrebných na vykonanie testov. Je nutné si uvedomiť, že autor testu musí vytvoriť inštanciu servletu ručne. Cactus nie je servlet kontajner a nedokáže vytvoriť inštanciu servletu sám. Nasleduje samotné testovanie pomocou JUnit testovacích metód, ktoré majú zistiť, či logika servletu sa vykonala správne alebo zlyhala. Po ukončení testXXX() metódy zavolá redirektor metódu tearDown().
6. Redirektor proxy zhrnie výsledky a prípadne vzniknuté výnimky.
7. Následne sa získané výsledky pošlú klientovi.
8. Ak test nespadol, zavolá sa (ak existuje) nepovinná metóda endXXX(WebResponse). Teda ak naša testovacia metóda sa volá testGetCustomerName(), potom Cactus hľadá metódu s názvom endGetCustomerName(WebResponse). Táto metóda môže vykonávať rôzne logické operácie nad informáciami poslanými servletom či JSP.

Vaším cieľom na začiatku určite bude správne nastaviť Cactus tak, aby bolo možné testovať minimálne servlety a stránky JSP. Základným predpokladom je nakopírovať balíčky junit.jar, cactus.jar, commons-httpclient.jar, commons-logging.jar a nakoniec aspectjrt.jar na klienta tak, aby boli dostupné v classpath.

Čo sa týka strany servera, treba nakopírovať súbory junit.jar, cactus.jar, commons-logging.jar do adresára „WEB-INF/lib“ vašej webovej aplikácie. Len na okraj poznamenám, že názvy jednotlivých súborov navyše obsahujú číslo verzie daného nástroja. Vysvetlime si teraz obsah jednotlivých balíkov:

• junit.jar – obsahuje JUnit framework, z ktorého Cactus vychádza a ktorý je potrebný na kompiláciu a beh Cactus testov
• cactus.jar – samotný Cactus framework vrátene spomínaných troch test caseov (ServletTestCase, JspTestCase, FilterTestCase)
• commons-httpclient.jar – framework obsahujúci podporu pre HTTP metódy GET a POST, posielanie cookies a BASIC autentifikáciu
• commons-logging.jar – Jakarta Commons Logging framework, ktorý Cactus potrebuje ako rozhranie na pripojenie rôznych logovacích pluginov, napríklad log4J (aj keď sa rozhodnete logovanie nepoužívať, trieda HttpClient toto rozhranie potrebuje)
• aspectjrt.jar – je používaný Cactusom na vykonávanie úloh typu kontrola konfigurácie a logovanie na začiatku a konci behu rôznych testovacích metód

Pre lepšiu názornosť a pochopenie závislostí a umiestnenia jednotlivých balíčkov si prezrite nasledujúci obrázok:

Voliteľne si ešte môžete nakopírovať na klienta a server aj súbor log4j.jar, ak chcete využívať možnosti logovacieho nástroja log4J. Ďalej je ešte možné využiť balíčky httpunit.jar, tidy.jar a xerces.jar v prípade, ak plánujete používať HttpUnit vo vašich testoch.

Cactus využíva na nastavenie základných parametrov konfiguračný súbor cactus.properties. V budúcom článku si ukážeme, čo a v akej forme by mal tento súbor obsahovať a prejdeme si kroky, potrebné na napísanie Cactus testu.

Odkazy, zdroje

• Cactus framework – oficiálna stránka testovacieho frameworku Cactus
• Cactus framework download – download binárnych archívov

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.