1. Wstęp - podstawy teoretyczne

Testowanie aplikacji

jakość jest za darmo („Quality Is Free” - Philip B. Crosby) w tym sensie, że koszty zapewnienia jakości – w tym testowania – są zwykle znacznie niższe niż koszty awarii spowodowanych brakiem testowania

Źródło: Bogdan Bereza-Jarociński , „Test w banku”, kwartalnik TESTER.PL, nr 1, str.8

Model V

model V

Obrazek: Joanna Nowakowska, Lucjan Stapp „Test Driven Development”, kwartalnik TESTER.PL, nr 4, str.28

Testy modułowe

Tworzone przez programistów,
Umożliwiają szybkie znalezienie miejsca wystąpienia błędu,
Uniemożliwiają ukrycie błędu przez działanie innego modułu,
Niski koszt (szczególnie w porównaniu z innymi testami),

white box

Obrazek: Vincent Massol, „Unit Testing J2EE applications”

XUnit

XUnit – rodzina narzędzi przeznaczonych do testów modułowych (w zależności od języka programowania):

Java – JUnit (http://junit.org/index.htm),
Visual Basic – VBUnit (http://www.vbunit.org),
C++ - CPPUnit (http://cppunit.sourceforge.net),
C# - NUnit (http://www.nunit.org).”

Źródło: Joanna Nowakowska, Lucjan Stapp „Test Driven Development”, kwartalnik TESTER.PL, nr 4, str.31

JUnit

Biblioteka pozwalająca na tworzenie powtarzalnych testów

Elementy biblioteki:
- abstrakcyjna klasa TestCase, z wykorzystaniem której tworzony jest przypadek testowy (klasa zawiera metody setUp() i tearDown() – co umożliwia ładowanie danych wejściowych potrzebnych do wykonania przypadku oraz czyszczenie po wykonaniu testu);
- klasa Assert, zawierająca zestaw asercji porównujących wyniki oczekiwane z rzeczywistymi;
- klasy TestRunner (junit.textui.TestRunner i junit.swingui.TestRunner) umożliwiające wykonanie przypadku testowego;
- klasa TestSuite, umożliwiająca grupowanie większej ilości przypadków testowych.
  
  Źródło: Joanna Nowakowska, Lucjan Stapp „Test Driven Development”, kwartalnik TESTER.PL, nr 4, str.34

2. Cactus

odpowiednik JUnit dla aplikacji J2EE

Cactus jest narzędziem służącym do przeprowadzania testów modułowych kodu aplikacji serwerowych (Servlety, EJB, Tag Libs, Filters, ...)
testy wykonywane są wewnątrz kontenera serwera aplikacji

Wady i zalety

koszt
czas
jakość

Rozwiązania alternatywne

mock objects
JUnit

3. Przykłady i ćwiczenia

Źródło: oficjalna strona projektu Cactus

Przykład 1

Wymagania wstępne

1. Instalacja tomcata:
http://tomcat.apache.org/download-55.cgi#5.5.17
2. Skopiowanie cactusowych jar'ów (katalog [cactus]/lib)
http://jakarta.apache.org/site/downloads/downloads_cactus.cgi
do katalogu [tomcat-root]/common/lib
3. Edycja pliku web.xml ([tomcat]/conf/web.xml)

Należy dodać na początku pliku [tomcat-root]/conf/web.xml (za tagiem <webapp>) następujący wpis:

<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>value1 used for testing</param-value>
</init-param>
</servlet>

<servlet>
<servlet-name>ServletTestRunner</servlet-name>
<servlet-class>org.apache.cactus.server.runner.ServletTestRunner</servlet-class>
</servlet>

A za ostatnim tagiem <servlet>:

<servlet-mapping>
    <servlet-name>ServletRedirector</servlet-name>
    <url-pattern>/ServletRedirector</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>ServletTestRunner</servlet-name>
    <url-pattern>/ServletTestRunner</url-pattern>
</servlet-mapping>

Przykładowa aplikacja

SampleServlet.java:
-------

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;

public class SampleServlet extends HttpServlet
{
    public void saveToSession(HttpServletRequest request)
    {
        String testparam = request.getParameter("testparam");
        request.getSession().setAttribute("testAttribute", testparam);
    }
}

-------
kompilacja:

javac -classpath[tomcat-root]/common/lib/servlet-api.jar:. SampleServlet.java

TestSampleServlet.java:
-------

import junit.framework.Test;
import junit.framework.TestSuite;

import org.apache.cactus.ServletTestCase;
import org.apache.cactus.WebRequest;

public class TestSampleServlet extends ServletTestCase
{
    public TestSampleServlet(String theName)
    {
        super(theName);
    }

    public static Test suite()
    {
        return new TestSuite(TestSampleServlet.class);
    }

    public void beginSaveToSessionOK(WebRequest webRequest)
    {
        webRequest.addParameter("testparam", "it works!");
    }

    public void testSaveToSessionOK()
    {
        SampleServlet servlet = new SampleServlet();
        servlet.saveToSession(request);
        assertEquals("it works!", session.getAttribute("testAttribute"));
    }
}

-------
javac -classpath [tomcat-root]/common/lib/junit-3.8.1.jar:[tomcat-root]/common/lib/cactus-1.7.2.jar:[tomcat-root]/common/lib/servlet-api.jar:. TestSampleServlet.java

Skopiować skompilowane pliki (class) do katalogu:
[tomcat-root]/webapps

I odpalić test w przeglądarce:

http://localhost:8080/test/ServletTestRunner?suite=TestSampleServlet
http://localhost:8080/test/ServletTestRunner?suite=TestSampleServlet&xsl=cactus-report.xsl

Przykład 2

apache-tomcat-5.5.17/webapps/test2/src
http://localhost:8080/test2/ServletTestRunner?suite=TestSampleServlet&xsl=cactus-report.xsl

Przykład 3

http://localhost:8080/cactus-sample-servlet/ServletTestRunner?suite=org.apache.cactus.sample.servlet.TestSampleServlet&xsl=cactus-report.xsl

Ćwiczenie 1

Skompiluj i uruchom przykłady "ejb" i "jetty".

Ćwiczenie 2

Zmodyfikuj testy z ćwiczenia 1 (i/lub przykładów) tak by miały status "failed" (zakończyły się niepomyślnie).

Ćwiczenie 3

Zmodyfikuj aplikacje (nie testy!) z ćwiczenia 1 (i/lub przykłady) tak żeby pliki wynikowe przeszły napisane testy pozytywnie, a potem tak by nie przeszły testów.