Ausarbeitung - Institut für Wirtschaftsinformatik der WWU Münster ...

Westfälische Wilhelms-Universität Münster
Ausarbeitung
Testen von Webanwendungen mit
HttpUnit und Cactus
im Rahmen des Seminars „Ausgewählte Themen des Softwareengineering“
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Prof. Dr. Herbert Kuchen
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Volker Frehe

Inhaltsverzeichnis
1 Einleitung................................................................................................................... 3
2 Grundlagen des Testens............................................................................................. 4
2.1 Ausgewählte Arten von Testverfahren ............................................................. 4
2.2 Testen mit JUnit................................................................................................ 4
3 Testen von Webanwendungen................................................................................... 6
3.1 Testen mit HttpUnit .......................................................................................... 6
3.1.1 Aufbau einer Verbindung ............................................................................. 7
3.1.2 Ausgewählte Methoden von HttpUnit zum Extrahieren von Elementen ..... 7
3.1.3 Auswertung der Ergebnisse ........................................................................ 10
3.2 Testen mit Jakarta Cactus ............................................................................... 12
3.2.1 Generelle Funktionsweise von Jakarta Cactus............................................ 13
3.2.2 Testen von Servlets..................................................................................... 14
3.2.3 Testen von Servlet-Filtern .......................................................................... 15
3.2.4 Testen von JSPs .......................................................................................... 16
4 Zusammenfassung und Fazit ................................................................................... 17
Literaturverzeichnis ........................................................................................................ 18
II

Kapitel 1: Einleitung
1 Einleitung
Testen ist eine der wichtigsten Stufen bei der Entwicklung von Software. Fehler, die
erst im fertigen Produkt aufgefunden werden, können meist gar nicht oder nur unter
enormen Kosten nachträglich behoben werden. Gerade unter diesem Kostenaspekt wird
dem Testen eine immer bedeutendere Rolle zugewiesen und Ausreden wie „Ich habe
keine Zeit zum Testen“ oder „Ich programmiere fehlerfrei“ sind nicht mehr akzeptabel.
Somit ist das Testen nicht nur auf die reine Testabteilung beschränkt, sondern wird
immer mehr in die Hände des Programmierers gelegt, um frühzeitig Fehler zu erkennen
und zu beheben.
Bei der Entwicklung von Webanwendungen kommt dem Testen noch eine weitere
wichtige Bedeutung zu. Da die Anwendung nicht nur rein firmenintern läuft, sondern
weltweit abgerufen werden kann, muss sichergestellt werden, dass die Anwendung auch
auf den verschiedenen Browsern und Systemen fehlerfrei funktioniert.
Um die Kosten und den Aufwand für die Tests in einem angemessenen Rahmen zu
halten, bietet es sich an, die Tests nicht manuell durchzuführen, sondern hierfür eine
geeignete Software zu benutzen und die Tests zu automatisieren. Dies hat den Vorteil,
dass zum einen die Tests wesentlicher schneller durchgeführt werden können. Des
Weiteren sind die Tests so reproduzierbar und können nach einer Änderung des Codes
mit denselben Daten, welche zum Beispiel in einer Datenbank abgelegt werden, erneut
ausgeführt werden.
Ziel dieser Arbeit ist es, zwei Frameworks, nämlich HttpUnit und Jakarta Cactus,
welche beide eine Erweiterung des Programms JUnit sind, für das Testen von
Webanwendungen vorzustellen. Hierzu werden zuerst in Kapitel 2 verschiedene
ausgewählte Testarten vorgestellt. Kapitel 3 enthält einen Überblick über die
Funktionsweise von HttpUnit und Jakarta Cactus. In Kapitel 4 wird ein kurzer
Vergleich der beiden Programme gegeben und erläutert, für welche Arten von
Webanwendungen sie geeignet sind.
3

Kapitel 2: Grundlagen des Testens
2 Grundlagen des Testens
2.1 Ausgewählte Arten von Testverfahren
Das Testen von Software kann in verschiedenster Weise und zu verschiedenen
Zeitpunkten der Software-Entwicklung vorgenommen werden. In Anlehnung an
[KWTRF06] werden hier vier wichtige Testarten beschrieben. In Unit-Tests werden
einzelne Komponenten der Anwendung, wie zum Beispiel Klassen oder Methoden,
getestet. Durch Integrationstests wird anschließend geprüft, ob diese Komponenten mit
dem Rest des Systems einwandfrei funktionieren. Der funktionale Test wird
ausgeführt, um zu testen, ob das gesamte System entsprechend seinem
Verwendungszweck einwandfrei arbeitet. Stresstests sollen das Verhalten des fertig
entwickelten Systems unter starker Belastung überprüfen, um einen fehlerfreien Betrieb
im Extremfall zu Gewähr leisten.
Eine weitere Unterscheidung kann in so genannte Glass-Box- und Black-Box-Tests
erfolgen. Bei Glass-Box-Tests ist dem Tester der komplette Quellcode bekannt,
wohingegen der Tester bei Black-Box-Tests lediglich das fertige Programm und nicht
den Quellcode selber sieht.
Dies ist natürlich nur eine Auswahl von verschiedenen Testarten. Oft lassen sich Tests
auch nicht in eine einzelne Kategorie einordnen, sondern stimmen mit mehreren
Definitionen überein.
2.2 Testen mit JUnit
JUnit ist eine Software, um Unit-Tests für Java-Anwendungen zu schreiben. Die
Testfälle sind selber in Java geschriebene Klassen, welche die zu testenden Methoden
aufrufen und ihre zurück gelieferten Werte überprüfen. Diese Klassen haben alle die
JUnit Klasse TestCase als Superklasse, um bestimmte bereitgestellte Methoden zum
Testen benutzen und gegebenenfalls erweitern zu können.
Um die zu testenden Methoden zu überprüfen, bietet JUnit einige Hilfsmethoden, die so
genannten asserts, an. Die Methoden sind so aufgebaut, dass als erster (optionaler)
Parameter eine Meldung angegeben wird, die bei Fehlschlag angezeigt wird. Die
weiteren Parameter sind die Konditionen, die zu vergleichen sind. Eine oft benutzte
4

Kapitel 2: Grundlagen des Testens
assert-Methode ist assertEquals ([String message,] expexted, actual).
Hiermit können die beiden Parameter expected und actual auf Übereinstimmung
getestet werden. Die Methode assertTrue ([String message,] boolean
condition) überprüft einen Ausdruck und gibt die Fehlermeldung aus, wenn er nicht
wahr ist [Li05].
Um einen Test auszuführen, müssen oft auch weitere Parameter, die nicht durch die zu
testende Methode festgelegt werden, vorher auf einen bestimmten Wert festgelegt
werden oder Verbindungen aufgebaut werden. Hierzu bietet JUnit die beiden Methoden
setUp() und tearDown() an. Diese können in den Testklassen überschrieben werden
und werden jeweils vor dem Test bzw. nach dem Test ausgeführt. Die Tests selber
werden von JUnit eigenständig erkannt, sofern sie als testXXX() benannt sind [Li05].
Die fertigen Testfälle werden dann mit dem JUnit TestRunner ausgeführt. Diesen gibt
es zum einen als textbasierte Benutzeroberfläche, aber auch als grafische Variante. Bei
der grafischen Variante wird mittels eines Balkens, entweder rot für einen Fehlschlag
oder grün für den Erfolg, das Ergebnis des Testens dargestellt. Außerdem gibt er die
Fehlermeldung (wenn angegeben) aus.
Abbildung 1: Erfolgreicher JUnit-Test [Ju07]
5

Kapitel 3: Testen von Webanwendungen
Abbildung 2: Fehlgeschlagener JUnit-Test [Ju07]
Durch diese einfachen Methoden und die übersichtliche Auswertung lassen sich schnell
Testfälle entwickeln, welche parallel zum zu entwickelnden Projekt ausgeführt werden
und somit zu einer fehlerfreien Programmierung führen.
3 Testen von Webanwendungen
HttpUnit und Jakarta Cactus stellen keine eigenständige Testsoftware dar, sondern sind
lediglich Erweiterungen, welche auf JUnit aufbauen. Wie schon der Name sagt, lassen
sich mit JUnit Unit-Tests durchführen, was jedoch bei HttpUnit und Jakarta Cactus
nicht der Fall ist. Beide Erweiterungen stellen Funktionen und Schnittstellen zur
Verfügung, um Webanwendungen zu testen. Bei HttpUnit handelt es sich um (Black-
Box) funktionale Tests und bei Jakarta Cactus um so genannte (White-Box)
Integrations-Tests.
3.1 Testen mit HttpUnit
Um Webanwendungen zu testen, verfügt HttpUnit über eine API sowie diverse
Methoden, um Anfragen an einen Server zu senden und Antworten von ihm zu
empfangen. HttpUnit stellt somit eine Schnittstelle zwischen dem Testprogramm
(JUnit) und dem Http-Protokoll dar, in dem es ausgewählte Eigenschaften eines
Browsers simuliert, wodurch das Senden und Empfangen von Http-Anfragen
ermöglicht wird. Des Weiteren bietet HttpUnit Methoden, um Formulare mit
6

Kapitel 3: Testen von Webanwendungen
entsprechenden Daten zu füllen und abzusenden, Links zu verfolgen, aber auch Cookies
zu empfangen und Teile aus den zurück gelieferten Daten zu extrahieren.
3.1.1 Aufbau einer Verbindung
Um eine Verbindung mit dem Server aufzubauen und einen Request zu senden, wird
zuerst mittels eines erzeugten WebConservation Objektes eine Sitzung gestartet. Die
Klasse WebRequest enthält nun Methoden, mit deren Hilfe es möglich ist, eine Anfrage
inklusive der URL zu der zu testenden Anwendung sowie die erforderlichen Parameter
an den Server zu senden. Die Antwort kann danach in einem Objekt WebResponse
empfangen werden und enthält sowohl die Seite selber als auch Metadaten wie Cookies.
Im folgenden Beispiel wird nun eine neue Verbindung mit dem Internet hergestellt, eine
Anfrage gesendet und das Ergebnis empfangen [HOVPG04, S. 300]:
WebConversation conv = new Webconversation();
WebRequest req = new GetMethodWebRequest(“http://www.wi.unimuenster.de/”);
WebResponse response = conv.getResponse(req);
Der Code lässt sich noch weiter abkürzen, in dem man die URL direkt in den
WebResponse einbaut und den WebRequest komplett weglässt:
WebConversation conv = new Webconversation();
WebResponse response = conv.getResponse(“http://www.wi.unimuenster.de/”);
Zu beachten ist hier, dass dies lediglich eine Anfrage an den Server und Antwort von
diesem ist. Eine Auswertung der zurück gelieferten Antwort findet hierbei noch nicht
statt.
3.1.2 Ausgewählte Methoden von HttpUnit zum Extrahieren von
Elementen
Zur Auswertung der zurück gelieferten Seiten stehen dem Programmierer verschiedene
Klassen mit diversen Methoden zur Verfügung, um Teile aus der Antwort zu separieren
und diese mit den JUnit assert-Methoden zu überprüfen.
7

Kapitel 3: Testen von Webanwendungen
Abbildung 3: Ausgewählte Klassen von HttpUnit [Fe04]
Eine Möglichkeit ist, aus dem empfangenen Ergebnis die übermittelten Links
herauszufiltern. Dies funktioniert mit getLinkWith(“string”), wobei der string der
klickbare Text und nicht die URL des Links ist. Zum einen kann hiermit geprüft
werden, ob ein gewünschter Link auch in der Seite enthalten ist, zum anderen ist es aber
auch möglich, diesen Link zu verfolgen und eine neue Anfrage mit diesem Link an den
Server zu schicken. Will man zum Beispiel über eine Start-Seite zu einer
weiterführenden Seite gelangen, deren Link als Text „Weitere Infos“ enthält, erreicht
man dies mit folgendem Code [HOVPG04, S. 300]:
WebConversation conv = new Webconversation();
WebResponse response = conv.getResponse(“http://www.wi.unimuenster.de/”);
WebLink link = response.getLinkWith(“Weitere Infos”);
WebRequest request = link.getRequest();
response = conv.getResponse(request);
Da Webanwendungen meist aus Formularen bestehen, die Eingaben erfordern, stellt
HttpUnit auch Methoden bereit, um Formulardaten zum einen auszufüllen aber auch um
das Formular schließlich abzuschicken. Als Beispiel sei hier eine kleine Anwendung
8

Kapitel 3: Testen von Webanwendungen
gezeigt, welches ein Loginscript mit Usernamen und Passwort enthält: [HOVPG04, S.
302 f.]:
Abbildung 4: Html-Seite mit Login-Formular
WebConversation conv = new Webconversation();
WebResponse response = conv.getResponse(“http://www.wi.unimuenster.de/”);
WebForm form = response.getForms()[0];
WebRequest loginreq = form.getRequest();
loginreq.setParameter (“username”, user);
loginreq.setParameter (“password”, pass);
WebResponse loginresponse = conv.getResponse(loginreq);
Die ersten beiden Zeilen des Codes sind bekannt. Mit Zeile drei wird nun das erste
Formular der Antwort ausgewählt. Mit dem ausgewählten Formular kann man nun
einen neuen Request an den Server formulieren, welches in Zeile vier geschieht. Zeile
fünf und sechs weisen den Parametern username und password noch die entsprechenden
Werte zu, um schließlich in Zeile sieben die Anfrage abzusenden und die Antwort zu
erhalten.
Während die ersten beiden Beispiele dazu dienten, von einer zur nächsten Seite zu
navigieren, bietet die Klasse WebResponse auch Methoden, um Teile aus der der
Antwort des Servers zu extrahieren. Als Beispiel seien hier einige Methoden genannt,
mit denen es möglich ist, spezielle Tabellen auszuwählen:
public WebTable[] getTables()
public WebTable getTableStartingWith(String text)
public WebTable getTableStartingWithPrefix(String text)
public WebTable getTableWithID(String text)
public WebTable getTableWithSummary(String text)
Es gibt noch weitere Methoden, um speziellen Content zu extrahieren. Dies kann nicht
nur mit Hilfe der von HttpUnit bereit gestellten Methoden erfolgen, sondern der
9

Kapitel 3: Testen von Webanwendungen
Programmierer selbst kann mit Hilfe der Methode getDOM() durch die Knoten einer
Seite navigieren und sich spezielle Instanzen rückliefern lassen. Ermöglicht wird dieses
dadurch, dass die Syntax von Webseiten dem Document Object Model (DOM) des
World Wide Web Consortium unterliegt. Die bereitgestellten Methoden der Klasse
WebResponse nutzen ebenfalls diese Struktur, um den Content zu extrahieren. Die
Struktur des zurück gelieferten Ergebnisses ist somit wie ein Baum aufgebaut, dessen
Knoten von der Wurzel an durchsucht werden können. Dies ermöglicht, bestimmte
Werte (zum Beispiel alle als deklarierten Überschriften) in eine Tabelle oder
einen Vektor zu schreiben und somit vom Rest des Contents zu separieren.
HttpUnit gibt nicht nur die Möglichkeit, Zugriff auf den Content einer Webseite zu
erhalten, sondern kann auch mit Cookies arbeiten. Hierfür stehen zwei Methoden der
Klasse WebResponse bereit, zum einen getNewCookieNames() und
getNewCookieValue(). Hierdurch kann überprüft werden, ob der Server versucht,
ein Cookie zu setzen und ob die Werte, die das Cookie zu setzen versucht, die Richtigen
sind.
3.1.3 Auswertung der Ergebnisse
Alleine das Separieren von Teilen der übermittelten Seite sagt natürlich noch nichts
über die Korrektheit der Daten aus. Hierzu müssen die empfangenen dann mit den
erwarteten Daten verglichen werden. Bedenkt man, dass jede einzelne Seite einer
Webanwendung anders ist, müsste man hier im Grunde für jede eine eigene Testklasse
schreiben. Der Aufwand hierfür ist allerdings größer als der daraus erzielte Nutzen. Aus
diesem Grund werden Testfälle nur für Seiten geschrieben, bei denen der manuelle
Aufwand des Testens größer ist als der Aufwand des Schreibens eines Testfalls für die
Anwendung. Ein denkbarer Fall hierfür ist zum Beispiel ein Formular mit mehreren
Eingabemöglichkeiten und daraus resultierenden verschiedenen Ergebnissen. Hier
durchläuft das Testprogramm dann eine Tabelle mit den möglichen Eingaben und
vergleicht die zurück gelieferten Ergebnisse mit den ebenfalls in der Tabelle
gespeicherten richtigen Ergebnissen. Auch wenn dies bei einem einmaligen Test den
gleichen Aufwand wie bei einem manuellen Test aufweist, so reduziert sich der
Aufwand schon, wenn man ein zweites Mal testet, nachdem sich zum Beispiel etwas an
der Seite geändert hat. Da der Test selber nicht geändert werden muss, kann er erneut
wieder eingesetzt werden.
10

Kapitel 3: Testen von Webanwendungen
Ein Beispiel hierfür ist das oben genannte Login-Formular. Erscheint nach dem Login
eine Seite mit dem Titel „Login erfolgt“, kann durch einfaches Testen geprüft werden,
ob der Login erfolgreich war:
WebConversation conv = new Webconversation();
WebResponse response = conv.getResponse(“http://www.wi.unimuenster.de/”);
WebForm form = response.getForms()[0];
WebRequest loginreq = form.getRequest();
loginreq.setParameter (“username”, user);
loginreq.setParameter (“password”, pass);
WebResponse loginresponse = conv.getResponse(loginreq)
assertEquals (“Login erfolgt”, loginresponse.getTitle());
Hier wurde nun einfach geprüft, ob der Titel der empfangenen Seite mit dem erwarten
übereinstimmt. Sollte dies der Fall sein, erscheint im JUnit TestRunner ein grüner
Balken und der Test wurde erfolgreich ausgeführt. Schlägt der Vergleich fehl, so wird
der Balken im TestRunner rot und der Fehler wird ausgeliefert.
Ein weiterer möglicher Einsatz ist das Schreiben eines Tests, welcher Gegebenheiten
testet, die auf verschiedene Seiten zutreffen. So ist laut [HOVPG04] das Testen aller
Links auf einer Seite und aller weiterführenden Links mit einer einfachen Testklasse
möglich:
private WebConversation conversation;
private Set checkedlinks;
private String host = www.uni-muenster.de;
public void setUp(){
conversation = new WebConversation();
checkedLinks = new HashSet();
}
public void testEntireSite() throws Exception{
WebResponde response =
conversation.getResponse(“http://”+host);
checkAllLinks(response);
System.out.prinln(“Alle Links überprüft”);
}
private void checkAllLinks (WebResponse response) throws
Exception{
if(!isHtml(response))return;
WebLink[] links = response.getLinks();
for(int i = 0; i < links.length; i++){
boolean newLink = checkedLinks.add(links[i].getURLString());
if(newLink){
checkLink(links[i]);
}
}
}
11

Kapitel 3: Testen von Webanwendungen
private boolean isHtml(WebResponse response){
return response.getContentType().equals(“text/html);
}
private void checkLink(WebLink link) trhows Exception{
WebRequest request = link.getRequest();
java.net.URL url = request.getURL();
String linkHost = url.getHost();
if(linkHost.equals(this.host)){
WebResponse response = conversation.getResponse(request);
this.checkAllLinks(response);
}
}
Zuerst wird hier wieder mit setUp() eine Verbindung mit einem Server aufgebaut und
ein Hashset für die zu überprüfenden Links bereitgestellt. Mit testEntireSite()
wird nun eine Anfrage an der Server gestellt und danach checkAllLinks()
aufgerufen. Die Methode checkAllLinks() ruft zuerst isHtml() auf, um zu
überprüfen, ob es sich auch um eine (auswertbare) Html-Seite handelt. Sollte dies der
Fall sein, werden alle in der Seite enthaltenen Links in ein Array geschrieben. Dieses
Array wird nun durchwandert und für jeden Eintrag die Methode checkLink()
aufgerufen. Hier wird nun überprüft, ob es sich um einen internen oder externen Link
handelt. Externe werden nicht überprüft, da sie nicht zum eigenen Projekt gehören.
Handelt es sich um einen internen Link, wird für diesen Link ein Request durchgeführt.
Wird dabei ein ungültiges Ergebnis zurückgeliefert, so handelt es sich um einen
defekten Link und die Exception wird ausgelöst, die wieder im JUnit TestRunner
ausgegeben wird. Da rekursiv alle Links der Webseite überprüft werden, können so alle
fehlerhaften Links entdeckt werden. Um ein anderes Projekt zu testen, muss lediglich
der Host geändert werden. Dies ist nur ein kleiner Testfall, der sich lediglich auf
statische Inhalte anwenden lässt, da dynamische Seiten und Formulare ignoriert werden.
3.2 Testen mit Jakarta Cactus
Im Gegensatz zu HttpUnit, bei dem funktionale Tests von Webseiten durchgeführt
wurden, werden bei Jakarta Cactus Integrations-Tests durchgeführt. Cactus stellt hierzu
drei Unterklassen bereit, um serverseitigen Java-Code zu testen. Hiermit ist es möglich,
Servlets [HOVPG04, S. S. 361], JSPs [HOVPG04, S. 371] und Servlet Filter
[HOVPG04, S.365] zu testen. Weiterhin ermöglicht es, EJBs [HOVPG04, S. 394] mit
Cactus zu testen. Da dies aber keine spezielle Technik nur für Webanwendungen
darstellt, wird dies in dieser Arbeit nicht betrachtet.
12

Kapitel 3: Testen von Webanwendungen
3.2.1 Generelle Funktionsweise von Jakarta Cactus
Die Besonderheit bei Cactus ist, dass zwei Testfälle erzeugt werden, zum einen auf der
Clientseite, zum anderen auf der Serverseite.
Abbildung 5: Ausführung eines Cactus-Tests [Ja07]
Der JUnit Test Runner führt den Test zunächst auf der Clientseite aus. Hierzu wird die
Methode runTest() ausgeführt. Für jede testXXX() Methode wird nun nach einem
beginXXX() gesucht. In beginXXX() können auch weitere Parameter gesetzt werden,
welche zur Ausführung des serverseitigen Codes notwendig sind. (1)
Anschließend wird eine Verbindung mit einem Redirector aufgebaut und der Request,
mit allen ihm übergebenen Parametern, wird an ihn gesendet. (2)
Der Redirector fungiert auf Serverseite wie der JUnit Test Runner auf der Client Seite.
Hierzu wird der Redirector initialisiert und bekommt alle Parameter für die
Testausführung übergeben. (3)
Nach der Initialisierung führt der Redirector nacheinander die Methoden setUp(),
testXXX() und tearDown() aus. (4)
Bei der Ausführung der testXXX()-Methode werden der serverseitige Java-Code (JSP,
Servlet oder Servlet Filter) ausgeführt und JUnit Methoden zum Auswerten der
Ergebnisse benutzt. (5)
Die Ergebnisse des Tests (egal ob erfolgreich oder misslungen) werden vom Redirector
eingesammelt. (6)
Sind alle Tests ausgeführt, schickt der Redirector die Ergebnisse zurück zum Client. (7)
13

Kapitel 3: Testen von Webanwendungen
Wurden Fehler bei der Ausführung der Tests gefunden, so werden diese nun im JUnit
Test Runner angezeigt. Wurden keine Fehler gefunden, sucht runTest() nun nach
einem endXXX() und führt es aus. Hierbei ist es erneut möglich, die empfangenen
Daten mit JUnit zu überprüfen.
3.2.2 Testen von Servlets
Servlets stellen Java-Klassen dar, die Http-Anfragen entgegennehmen und diese
beantworten. Dabei kann je nach Parameter der Inhalt dynamisch erzeugt werden.
Jakarta Cactus stellt hierfür eine junit.framework.TestCase Unterklasse bereit:
org.apache.cactus.SevletTestCase
Um einen Testfall zu generieren, muss der Programmier drei Methoden erzeugen
(beginXXX(), testXXX() und endXXX()). Außerdem muss in der web.xml (einer
Datei, die bei der Installation von Cactus auf den Server gelegt wird) ein Eintrag
vorgenommen werden, damit der Testfall den entsprechenden Redirector für Servlets
benutzt [HOVPG04, S. 361]:
ServletRedirector
org.apache.cactus.server.ServletTestRedirector
ServletRedirector
/ServletRedirector
Mit der Methode beginXXX() wird eine Verbindung mit dem Server hergestellt. Ihm
werden zum einen die URL der zu testenden Seite übergeben als auch notwendige
Parameter zur Initialisierung. Des Weiteren können zum Beispiel noch Cookies für den
Request gesetzt werden [Ja07]:
public void beginXXX(WebRequest theRequest){
theRequest.setURL("uni-muenster.de", "/app", "/test.jsp", null,
null);
theRequest.addCookie("cookiename", "cookievalue");
}
Cactus erstellt automatisch ein WebRequest Objekt und stellt es unter den Namen
„response“ den Methoden setup(), testXXX() und teardown() bereit. Dieses
Objekt verweist auf das in beginXXX() erstellte WebRequest Objekt. In der
14

Kapitel 3: Testen von Webanwendungen
testXXX()-Methode wird nun das eigentliche Servlet getestet. Mit der Funktion
assertEquals() kann zum Beispiel der Inhalt von Attributen auf Übereinstimmung
überprüft werden [Ja07]:
public void testXXX(){
MyServletToTest servlet = new MyServletToTest();
servlet.init(config);
servlet.methodToTest();
assertEquals("someValue",
session.getAttribute("someAttribute"));
assertEquals("uni-muenster.de", request.getServerName());
}
Das zurück gelieferte Ergebnis kann nun noch in der endXXX()-Methode ausgewertet
werden. Hier kann wiederum ähnlich wie bei HttpUnit zum einen auf den Content des
Ergebnisses als auch auf MetaDaten und Cookies zugegriffen werden [Ja07]:
public void endXXX(WebResponse theResponse){
Cookie cookie = theResponse.getCookie("someCookie");
assertEquals("someValue2", cookie.getValue());
assertEquals("some content here", theResponse.getText());
}
3.2.3 Testen von Servlet-Filtern
Servlet-Filter dienen dazu, vor und/oder nach dem Zugriff auf ein Servlet Informationen
dem Servlet hinzuzufügen oder Informationen herauszufiltern und diese zum Beispiel
auf dem Server abzulegen. Um diese Filter zu testen, muss wieder eine spezielle
Testklasse eingebunden werden:
org.apache.cactus.FilterTestCase
Auch hier muss dem Programm mittels Eintrag in der web.xml mitgeteilt werden,
welcher Redirector verwendet wird:
FilterRedirector
org.apache.cactus.server.FilterTestRedirector
FilterRedirector
/FilterRedirector
Jetzt kann der eigentliche Test geschrieben werden. Die beginXXX()-Methode
funktioniert wie oben beschrieben und beschreibt lediglich den Request an eine Seite.
15

Kapitel 3: Testen von Webanwendungen
Mit der testXXX()-Methode kann nun ein Filter auf einen Response ausgeführt
werden. Im folgenden Beispiel wird ein Header und ein Footer dem Response zugefügt
[Ja07]:
public void testXXX() throws ServletException, IOException{
SampleFilter filter = new SampleFilter();
config.setInitParameter("header", "Kopf");
config.setInitParameter("footer", "Fuss");
filter.init(config);
FilterChain mockFilterChain = new FilterChain() {
public void doFilter(ServletRequest theRequest,
ServletResponse theResponse) throws IOException,
ServletException{
PrintWriter writer = theResponse.getWriter();
writer.print("Inhalt");
writer.close();
}
public void init(FilterConfig theConfig){
}
public void destroy(){
}
};
filter.doFilter(request, response, mockFilterChain);
}
Hier wird nun zuerst der Filter initialisiert, die Parameter für den Footer und Header
gesetzt und dann der Filter ausgeführt. Um zu testen, ob das zurück gelieferte Ergebnis
auch wirklich den Footer sowie den Header enthält, kann wieder die endXXX()-
Methode benutzt werden [Ja07]:
public void endXXX(WebResponse theResponse){
assertEquals("headersome
contentfooter", theResponse.getText());
}
Abschließend wird lediglich noch geschaut, ob die Informationen, die der Filter dem
Response hinzugefügt hat, auch vorhanden sind.
3.2.4 Testen von JSPs
JavaServer Pages (JSP) ist eine Technologie, die es erlaubt, Java-Code in statische
Inhalte einzubetten. Hierdurch ist es möglich, dass Inhalt und Design getrennt
voneinander behandelt werden und mittels der JSPs dynamische Inhalte eingebunden
werden. Eine Einbindung der entsprechenden Testklasse ist obligatorisch:
org.apache.cactus.JspTestCase
16

Kapitel 4: Zusammenfassung und Fazit
Um hier wieder dem Testfall einen Redirector zuzuweisen, muss dieser auf bekannte
Weise in die web.xml eingetragen werden.
Das Testen von JSPs beschränkt sich jedoch auf den Test der zurück gelieferten Seiten
(zum Beispiel HTML oder XML). Man stellt im Grunde lediglich eine Anfrage an diese
Seite mit dem integrierten JSP und übergibt die benötigten Parameter:
Danach kann wieder auf Client-Seite die Antwort mit endXXX() ausgewertet werden.
Da das zurück gelieferte Ergebnis einer „normalen“ Internetseite entspricht, können hier
wieder von JUnit bereit gestellte Methoden verwendet werden, um das Ergebnis
auszuwerten.
4 Zusammenfassung und Fazit
Mit HttpUnit und Jakarta Cactus werden zwei unterschiedliche Erweiterungen für JUnit
bereitgestellt. Während mit HttpUnit funktionale Tests von Webanwendungen
durchgeführt werden, bietet Jakarta Cactus die Möglichkeit, Integrationstests für
serverseitige Java-Anwendungen durchzuführen.
Durch immer komplexer werdende Webanwendungen ist hier, wie auch in den anderen
Bereichen des Software Engineering, ein Testen des erstellten Codes für eine
komplikationslose Entwicklung erforderlich. Auf Grund der Simplizität der
bereitgestellten Methoden lassen sich schnell Testfälle entwickeln, um
Webanwendungen während der Entwicklung auf einwandfreie Funktion zu überprüfen.
Da die beiden Erweiterungen unterschiedliche Teile der Webanwendung testen und
somit unterschiedliche Tests durchführen, gibt es keine Bevorzugung einer Erweiterung.
Vielmehr braucht man für größere Projekte sowohl Jakarta Cactus als auch HttpUnit,
um die Anwendungen komplett zu testen. Um die Tests noch unkomplizierter zu
gestalten, bietet Jakarta bei seinem Cactus Projekt mittlerweile die Integration von
HttpUnit an.
Durch beide Erweiterungen besteht die Möglichkeit, manuelle Tests abzulösen und das
Testen wesentlich effizienter zu gestalten. Die Zeitersparnis auf Grund des Testens lässt
sich somit in andere Bereiche der Entwicklung Nutzen bringend einsetzen und steigert
hierdurch die Qualität des Endproduktes.
17

Literaturverzeichnis
[Fe04] Balazs Fejes, Test Web applications with HttpUnit,
http://www.javaworld.com/javaworld/jw-04-2004/jw-0419httpunit.html?page=1,
2004, Abrufdatum: 2007-04-18.
[HOVPG04] Richard Hightower, Warner Onstine, Paul Visan, Damon Payne, Joseph
D. Gradecki: Java Tools for extreme Programming, Wiley Publishing, 2004.
[Ja07] The Jakarta Projekt: Jakarta Cactus, http://jakarta.apache.org/cactus/,
Abrufdatum: 2007-04-20.
[Ju07] JUnit.org: JUnit, Testing Ressources for Extreme Programming,
http://www.junit.org/. Abrufdatum: 2007-05-10.
[KWTRF06] Axel Kalenborn, Thomas Will, Rouven Thimm, Jana Raab, Ronny
Fregin: Java-basiertes automatisiertes Test-Framework,
Wirtschaftsinformatik 48 (2006), S.437-445.
[Li05] Johannes Link: Softwaretests mit JUnit, dpunkt.verlag, 2005.