Dôležitou časťou Cactus frameworku je konfiguračný súbor, obsahujúci niekoľko užitočných informácií, potrebných na vykonanie testov. Tento súbor sa umiestňuje na klienta a musí byť dostupný v classpath. Tiež si popíšeme niekoľko základných krokov na úspešné vytvorenie testu.

Cactus využíva Java properties súbor s názvom cactus.properties, potrebný na špecifikovanie niekoľkých atribútov na klientskej strane. Okrem toho, že sa musí nachádzať v classpath, musí obsahovať informácie o web contexte vašej testovanej aplikácie a názvy konkrétnych redirektorov použitých pri testovaní. Názvy jednotlivých redirektorov odpovedajú názvom pod ktorými sú zaregistrované v deployment deskriptore webovej aplikácie web.xml. Nasleduje ukážka obsahu properties súboru:

cactus.properties

cactus.contextURL = http://localhost:8080/cactus
cactus.servletRedirectorName = ServletRedirector
cactus.jspRedirectorName = JspRedirector
cactus.filterRedirectorName = FilterRedirector

Teraz si trochu bližšie popíšeme význam jednotlivých atribútov cactus.properties súboru:

  • cactus.contextURL – je URL špecifikujúce server, číslo portu a názov webovej aplikácie (web context), určenej na testovanie.
  • cactus.servletRedirectorName – názov Cactus servlet redirektora, tak ako je uvedený v príslušnom elemente <url-pattern> vo web.xml. Tento atribút je povinný len vtedy, ak váš test je rozšírením org.apache.cactus.ServletTestCase triedy.
  • cactus.jspRedirectorName – má zhodný význam len sa týka JSP redirektora a triedy org.apache.cactus.JspTestCase.
  • cactus.filterRedirectorName – tiež má zhodný význam len sa týka Filter redirektora a triedy org.apache.cactus.FilterTestCase.

Konfigurácia na strane servera spočíva vo vytvorení resp. editovaní webového deskriptora web.xml, v ktorom je nutné správne vykonať registráciu jednotlivých Cactus redirektorov. Nasleduje príklad.

web.xml

<web-app>
  <filter>
    <filter-name>FilterRedirector</filter-name>
    <filter-class>
      org.apache.cactus.server.FilterTestRedirector
    </filter-class>
  </filter>
  <filter-mapping>
    <filter-name>FilterRedirector</filter-name>
    <url-pattern>/FilterRedirector</url-pattern>
  </filter-mapping>
  <servlet>
    <servlet-name>ServletRedirector</servlet-name>
    <servlet-class>
      org.apache.cactus.server.ServletTestRedirector
    </servlet-class>
  </servlet>
  <servlet>
    <servlet-name>JspRedirector</servlet-name>
    <jsp-file>/jspRedirector.jsp</jsp-file>
  </servlet>
  <servlet-mapping>
    <servlet-name>JspRedirector</servlet-name>
    <url-pattern>/JspRedirector</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>ServletRedirector</servlet-name>
    <url-pattern>/ServletRedirector</url-pattern>
  </servlet-mapping>
</web-app>

Ak chcete použiť JSP redirektor ako je uvedené v príklade, musíte pridať súbor jspRedirector.jsp k vašej aplikácii. Tento súbor nájdete v CACTUS_HOME/sample-servlet/web. Pokračujeme vytvorením základnej kostry testu. Je možné ju rozdeliť do siedmich krokov. Základom je napísať vlastné rozšírenie niektorého z Cactus test case-u a implementovať jednu alebo viac z testXXX( ), beginXXX( ) a endXXX( ) metód.

1. krok je vykonať import JUnit a Cactus tried:

import org.apache.cactus.*;
import junit.framework.*;

2. krok spočíva vo výbere testu ktorý chceme implementovať. Máme tri možnosti:

  1. org.apache.cactus.ServletTestCase – použite tento case, ak chcete vedieť ako servlet manipuluje s objektami HttpServletRequest, HttpServletResponse, HttpSession, ServletContext alebo ServletConfig.

    public class TestServlet extends ServletTestCase { … }

  2. org.apache.cactus.JspTestCase – môžete použiť, ak chcete testovať napríklad použitie užívateľských značiek (custom tags) a objektov JspWriter.

    public class TestJsp extends JspTestCase { … }

  3. org.apache.cactus.FilterTestCase – sa využíva pri testovaní servlet filtrov a správnej funkčnosti objektov FilterChain a FilterConfig.

    public class TestFilter extends FilterTestCase { … }

3. krok je voliteľná implementácia JUnit metód setUp() a tearDown(). Na rozdiel od JUnit frameworku sú tieto metódy vykonávané na strane servera, čo umožňuje pristupovať k implicitným objektom. Rovnako ako v JUnit sa metódy setUp() a tearDown() vykonávajú pre každú testXXX() metódu.

public void setUp() throws Exception {
  this.myobject = new MyObject();
  this.session.setAttribute(„ItemsID“, new Integer(1));
}

public void tearDown() throws Exception {
  this.session.removeAttribute(„ItemsID“);
  this.myobject = null;
}

4. krok je povinná implementácia testXXX() metód. V testovacej metóde je možné vytvoriť inštanciu servletu a prípadne ju inicializovať, ďalej zavolať metódy, ktoré majú byť otestované a nakoniec zavolať štandardné overovacie JUnit metódy. Overovacie metódy slúžia na overenie toho, či volaná metóda vrátila požadovaný výsledok. Nasleduje zoznam overovacích metód a príklad.

Metóda Popis
assertEquals() Porovná dve hodnoty na rovnosť. Test prejde, ak sa dané hodnoty rovnajú.
assertFalse() Očakáva logickú hodnotu false. V tom prípade je test úspešný.
assertNotNull() Porovná referenčný odkaz na objekt s hodnotou null. Test prejde, ak odkaz nie je null.
assertNotSame() Porovná adresy dvoch objektov v pamäti použitím == operátora. Test je úspešný, ak obidva odkazy ukazujú na iné objekty.
assertNull() Porovná referenčný odkaz na objekt s hodnotou null. Test prejde, ak odkaz je null.
assertSame() Porovná adresy dvoch objektov v pamäti použitím == operátora. Test je úspešný, ak obidva odkazy ukazujú na ten istý objekt.
assertTrue() Očakáva logickú hodnotu true. V tom prípade test je úspešný.
fail() Metóda spôsobí ukončenie testu. Často sa využíva v spojitosti s obsluhou výnimiek.

Všetky metódy akceptujú ako prvý argument reťazec s popisom danej overovacej metódy. Táto správa bude použitá v prípade, ak test neprejde.

public void testAddItemID() throws Exception {
  MyServlet servlet = new MyServlet();
  assertTrue(„ItemsID failed!“, servlet.doTrueOrFalse());
}

Čo sa týka vytvárania inštancie servletu, toto je činnosť ktorá sa bežne nerobí. Na starosti ju má servlet kontajner, lenže Cactus ním nie je. Preto zodpovednosť za životný cyklus servletu musí prebrať programátor.

5. krok je voliteľná implementácia beginXXX(WebRequest) metód, pričom pre každú testXXX() metódu je možné vytvoriť odpovedajúcu beginXXX(WebRequest) metódu. Metóda je vykonaná na strane klienta, preto nemá dostupné implicitné objekty.

public void beginAddItemID(WebRequest webRequest) {
  webRequest.addParameter(„itemID“, „12345“);
}

Táto metóda môže byť využitá napríklad na nastavenie HTTP parametrov, cookies a pod. Hodnoty, ktoré nastavíte tu, sú potom dostupné v metódach testXXX() prostredníctvom príslušných implicitných objektov.

6. krok je opäť voliteľný. Podobne ako v piatom kroku, pre každú testXXX() metódu si môžete vytvoriť korešpondujúcu endXXX(WebResponse) metódu. Táto metóda sa vykoná na klientovi po úspešnom vykonaní testovacej metódy. Ak tá skončí výnimkou, endXXX() metóda sa nevykoná.

Cactus framework umožňuje použiť dve varianty tejto metódy podľa toho, ktorý z objektov WebResponse použijete:

import org.apache.cactus.WebResponse
public void endAddItemID(WebResponse webResponse) {
  Cookie cookie = webResponse.getCookie(„cookie“);
  assertEquals(„value“, cookie.getValue());
}
import com.meterware.httpunit.WebResponse
public void endAddItemID((WebResponse webResponse) {
  Cookie cookie = webResponse.getCookie(„cookie“);
  assertEquals(„value“, cookie.getValue());
}

Prvá varianta používa objekt WebResponse, ktorý je súčasťou Cactus frameworku a poskytuje pomerne jednoduchý pohľad na informácie uložené v tomto objekte. Naproti tomu druhá varianta distribuovaná s HttpUnit poskytuje oveľa detailnejšie informácie s bohatším API.

7. krok zostáva už len skompilovať vytvorené triedy, nasadiť aplikáciu na server a spustiť testy.

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

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

Žádný příspěvek v diskuzi

Odpovědět