Die Dokumentation für Stripes Unit tests beschreibt sehr ausführlich, wie man mit Hilfe des MockServletContext eine Testinfrastruktur aufbaut, die es ermöglicht die ActionBeans ausserhalb des JEE-Containers zu testen. Dies funktioniert für klassische ActionBeans ganz wunderbar. Doch beim schreiben von Tests für ActionBeans im Wizard Mode fiel auf, dass die Simulation eines Submits nicht funktionierte. Im Wizard Modus erzeugt das Stripes FormTag ein zusätzliches verstecktes Formularfeld mit dem Namen “__fp”, welches alle Feldnamen des aktuellen Formulars in verschlüsselter Form enthält. Ohne dieses Feld verweigert der Stripes Dispatcher die Arbeit! Nimmt man nun einen beliebigen Wert und legt ihn in diesem Feld ab, so erzeugt das ebenfalls einen Fehler:(Der Rechtschreibfehler ist tatsächlich aus dem Framework.)

Stripes attmpted and failed to decrypt the non-null value in the 'fields present' field.

Auch ist es nicht sinnvoll, einen beliebigen Text mit Hilfe des CryptoUtil zu verschlüsseln. Der Submit kann dann zwar erfolgreich simuliert werden, jedoch werden sämtliche Validierungsregel ignoriert. Mit folgenden Zeilen Code, kann ein korrekter Wert für das “__fp” Feld erzeugt werden:

// Alle Feldnamen des aktuellen Formulars in eine Liste aufnehmen
   List fields = new ArrayList();
   fields.add("username");
   fields.add("password");
// Alle Feldnamen mit Trennzeichen zusammenfassen
   String hiddenFieldValue = HtmlUtil.combineValues(fields);
// servlet engine configurieren
   MockServletContext ctx = TestFixture.getServletContext();
   MockRoundtrip trip = new MockRoundtrip(this.ctx, YourCustomActionBean.class);
   HttpServletRequest request = (HttpServletRequest) trip.getRequest();
   hiddenFieldValue = CryptoUtil.encrypt(hiddenFieldValue, request);
   trip.setParameter(StripesConstants.URL_KEY_FIELDS_PRESENT, hiddenFieldValue);

Für das Testen der Feldvalidierung ist es wichtig, dass die Feldnamen mit dem Wert des <input name="" /> Name Attributes in dem jeweiligen Formular übereinstimmen. Denn es werden tatsächlich nur die Felder validiert, die aus dem decodiertem Inhalt des “__fp” Feldes ausgelesen werden können.

Angenommen der oben abgebildete Code wird in der setup() Methode eines Unit Tests ausgeführt und speichert das MockRoundtrip Object in einem privaten Member, könnte ein Beispieltest könnte dann so aussehen:

@Test
public void testLogin() throws Exception {
	trip.setParameter("username", "christophbuente");
	trip.setParameter("password", "secret");
	trip.execute("login");
	YourCustomActionBean bean = trip.getActionBean(YourCustomActionBean.class);
	Assert.assertTrue("Destination", "/account", trip.getDestination());
}

Ich hoffe, dass diese Informationen ausreichen, um sinnvolle Unit Tests für ActionBeans im Wizard Modus zu schreiben. Bei Fragen helfe ich gerne weiter. Und wie immer sind Kommentare sehr willkommen.

Canoo Webtest bietet dem Benutzer die Möglichkeit, eine Web-Anwendung automatisch zu testen. Basierend auf der Ant Technologie können Tests in einem menschenlesbaren XML-Dialekt deklariert werden. Ein simples Beispiel könnte so aussehen:

<steps>
  <invoke
    description="Loginseite aufrufen"
    url="/login" />
  <verifyTitle
    description="Seitentitel sollte folgender sein: "
    text="Anmeldung" />
  <setInputField
    description="Setze Benutzernamen"
    name="username"
    value="max.mustermann" />
  <setInputField
    description="Setze Passwort"
    name="password"
    value="mypassword" />
  <clickButton
    description="Klick den login Knopf"
    name="login" />
  <verifyTitle
    description="Seitentitel sollte folgender sein:"
    text="Willkommen"  />
</steps>

Doch als erstes muss Canoo Webtest heruntergeladen und installiert werden. Keine Angst, das geht schnell und unkompliziert. Für den produktiven Einsatz empfehle ich die neueste, stabile Version. Von den Snapshots muss ich leider abraten, da beim erzeugen eines Projektes wichtige Dateien fehlten. Nach dem herunterladen der build.zip Datei kann das Archiv in ein beliebiges Verzeichnis entpackt werden. In diesem Verzeichnis muss sich danach ein bin Verzeichnis befinden, welches die Ausführungsskripte für Windows und Unix beinhaltet.

Dieses Verzeichnis muss dem Ausführungspfad bekannt gemacht werden, sodass Canoo Webtest einwandfrei verwendet werden kann.

• Unter Windows geht das wie folgt:
  • In den Systemeinstellungen (Windows-Taste + Pause) wählt man den Reiter “Erweitert”.
  • Dort drückt man den Knopf “Umgebungsvariablen” und fügt eine neue Variable WEBTEST_HOME mit der entsprechenden Pfadangabe hinzu: “C:\Programme\Webtest” hinzu.
  • Anschließend bearbeitet man die Variable “Path” und fügt am Ende folgendes an: “;%WEBTEST_HOME%\bin”.
• Unter Linux/Unix:
  • setenv WEBTEST_HOME /usr/local/webtest
setenv PATH $PATH:$WEBTEST_HOME/bin in der ~/.login (tcsh)
  • export WEBTEST_HOME=/usr/local/webtest
export PATH=$PATH:$WEBTEST_HOME/bin in der ~/.bashrc oder ~/.bash_login (bash)

Canoo Webtest generiert auf Wunsch ein Beispielprojekt, mit dem man sofort loslegen kann. Auf der Kommandozeile führt man folgenden Befehl aus:

webtest.sh -f pfad/zur/webtest/installation/webtest.xml wt.createProject

Während der Ausführung wird man nach einem Projektnamen gefragt. Ein gleichnamiges Verzeichnis wird nach der Eingabe im aktuellen Verzeichnis angelegt. Das neu angelegte Projekt enthält ein paar Beispieltests und Vorlagen. Um die Tests auszuprobieren ruft man lediglich webtest.sh im Verzeichnis des neu erstellten Projektes auf. Nach Abschluß aller Tests wird im Verzeichnis results ein HTML Report erzeugt, der automatisch angezeigt wird.

Um eigene Tests zu verwenden, löscht man im Verzeichnis tests am besten alle Dateien bis auf allTests.xml und eine weitere beliebige Datei. In der Datei allTests.xml werden alle vorhandenen Testdateien aufgerufen. Sie stellt das Verzeichnis aller auszuführenden Tests dar.

<?xml version="1.0"?>
<project name="allTests" default="test">
  <target name="test" description="führt alle tests aus">
    <ant antfile="loginTest.xml"/>
  </target>
</project>

Der anderen Datei gibt man einen sprechenden Namen, in diesem Fall loginTest.xml. In dieser Datei wird ein Testfall deklariert, welcher so aussehen könnte:

<?xml version="1.0"?>
<!DOCTYPE project SYSTEM "../dtd/Project.dtd">
<project name="loginTest" default="test">
  <target name="test">
    <webtest name="loginTest">
      &config;
      <steps>
        <invoke
          description="Loginseite aufrufen"
          url="/login" />
        <verifyTitle
          description="Seitentitel sollte folgender sein: "
          text="Anmeldung" />
        <setInputField
          description="Setze Benutzernamen"
          name="username"
          value="max.mustermann" />
        <setInputField
          description="Setze Passwort"
          name="password"
          value="mypassword" />
        <clickButton
          description="Klick den login Knopf"
          name="login" />
        <verifyTitle
          description="Seitentitel sollte folgender sein:"
          text="Willkommen"  />
      </steps>
    </webtest>
  </target>
</project>

Sicher ist aufgefallen, dass in dieser Datei kein Server deklariert ist, der getestet werden soll. Jedoch steht als erstes Element im <webtest> Element folgender Text: &config;
Dieser verweist auf die Datei includes/config.xml, welche alle Einstellungen enthält. Hier können nun der Name, Port und Protokoll des zu testenden Server eingetragen werden:

<!--
Wie alle Dateien dieses Ordners, ist dieser Inhalt als DTD Entität verfügbar (in diesem Fall &config;)
-->;
<config
  host="www.meinserver.de"
  port="8080"
  protocol="http"
  basepath=""
  summary="true"
  saveresponse="true"
  resultfile="${wt.resultfile}"
  resultpath="${wt.resultpath}"
  haltonfailure="false"
  haltonerror="false" />

Um eine möglichst vollständige Testabdeckung zu erreichen, fügt man in separaten Dateien für alle erdenklichen Anwendungsfälle Tests hinzu und trägt Sie in die Datei allTests.xml ein. Eine Dokumentation der zur Verfügung stehenden Schritte (Steps) findet man in der Anleitung für die Canoo Webtest Core Steps. Über mehr oder weniger generische Anwendungsfälle und deren sinnvolle Abtestung kann gerne in den Kommentaren berichtet werden.

[ad#vert-banner]

Als Mittel der Wahl hat sich seit Jahren das sogenannte CAPTCHA etabliert. Dabei werden Bilder erzeugt, die auf unebendem Hintergrund verzerrte Zeichen darstellen. Der Benutzer muss diese sogenannte Challenge lösen, in dem er die Zeichenfolge in ein Formularfeld eingibt. Stimmen die eingegebenen Zeichen und die Zeichen auf dem Bild übereinstimmen. Hier macht man sich zu nutze, dass der Mensch besser abstrahieren kann, und die Buchstaben trotz widriger Umstände erkennen kann, wo eine Maschine scheitert.

Da ich das Rad nicht neu erfinden will, habe ich mich einer Bibliothek bedient, die diese Funktionalität zur Verfügung stellt, und sehr einfach in das aktuelle Projekt einzubinden ist. Meine Wahl fiel auf JCaptcha. Wie der Name vermuten läßt ist JCaptcha eine Java basierte Implementierung. Sie läßt sich in Java basierte Webprojekte sehr einfach integrieren.

Folgende Schritte sind notwendig:

1. Implementierung eines eigenen Servlets, welches mit der Auslieferung der generierten Bilder beauftragt wird.
2. Eintrag des Servlets und des Mappings in die web.xml
3. Implementierung eines Singleton, welches den CaptchaService zur Verfügung stellt.
4. Erstellen einer validierungsmethode zum Überprüfen der Benutzereingabe.

Der generelle Ablauf ist recht einfach. Das in der JSP mit Hilfe des <img src=”img.captcha”> referenzierte Bild wird von unserem Servlet bedient. Dieses erzeugt mit Hilfe des CaptchaService ein neues Bild und gibt es als jpg zurück. Der CaptchaService speichert in einer internen Map unter dem Schlüssel der jeweiligen session id das captcha response. Die Methode validateResponseForID des CaptchaService prüft, ob der eingegebene Text mit dem Bild übereinstimmt.

Das Servlet wird wie folgt implementiert:

import java.awt.image.BufferedImage;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.util.Locale;import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import com.octo.captcha.service.CaptchaServiceException;
import com.sun.image.codec.jpeg.JPEGCodec;
import com.sun.image.codec.jpeg.JPEGImageEncoder;
/**
 * @author Christoph Bünte
 *
 * @version $Revision: 1.5 $
 *
 * @created 11.10.2007
 *
 */
public class CaptchaServlet extends HttpServlet {

/**
  * The serial id for this class
  */
 private static final long serialVersionUID = -5555311841435084305L;

@Override
 public void init(ServletConfig servletConfig) throws ServletException {

super.init(servletConfig);
}

/**
  * Generiert das Captcha image in form eines bytearrays
  *
  * @param token
  *            SessionId
  * @param loc
  *            Locale Object für die Sprache des Benutzers
  * @return
  */
 private synchronized byte[] getCaptchaChallenge(String token, Locale loc) {

byte[] captchaChallenge = null;

try {
 		// create the captcha challenge
 		BufferedImage challenge = CaptchaServiceSingleton.getInstance()
 				.getImageChallengeForID(token, loc);

		// transform image data into jpeg byte array
 		ByteArrayOutputStream jpegOutputStream = new ByteArrayOutputStream();

		JPEGImageEncoder jpegEncoder = JPEGCodec
 				.createJPEGEncoder(jpegOutputStream);

		jpegEncoder.encode(challenge);

		captchaChallenge = jpegOutputStream.toByteArray();

 	} catch (IOException e) {
 		//TODO: Fehlerbehandlung
 	} catch (CaptchaServiceException e) {
 		//TODO: Fehlerbehandlung
 	}

	return captchaChallenge;

 }

@Override
 protected void doGet(HttpServletRequest request,

 		HttpServletResponse response) throws ServletException, IOException {

			// Hier benutzen wir die session id und das Locale Objekt des requests
			String token = request.getSession().getId();
 			Locale loc = request.getLocale();

			// hole das CAPTCHA challenge als JPEG
			byte[] captchaAsJpeg = getCaptchaChallenge(token, loc);

			// falls nicht verfügbar, sende http code 404 (resource not available)
			if (captchaAsJpeg == null) {
				response.sendError(HttpServletResponse.SC_NOT_FOUND);
			return;
			}

			// gibt ein response Objekt mit dem jpeg bild zurück
			// (für den browser: benutze keinen cache und verwirf den inhalt sofort)
			// set header

			response.setHeader("Cache-Control", "no-store");
			response.setHeader("Pragma", "no-cache");
			response.setDateHeader("Expires", 0);
			response.setContentType("image/jpeg");

			// sende bilddaten
			ServletOutputStream responseOutputStream = response.getOutputStream();
			responseOutputStream.write(captchaAsJpeg);
			responseOutputStream.flush();
			responseOutputStream.close();
 		}

}

Der Eintrag in die web.xml sieht so aus:

<servlet>
	<servlet-name>jcaptcha</servlet-name>
	<display-name>JCaptcha</display-name>
	<servlet-class>your.package.path.CaptchaServlet</servlet-class>
	<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
	<servlet-name>jcaptcha</servlet-name>
	<url-pattern>*.captcha</url-pattern>
</servlet-mapping>

Das CaptchaService als Singleton implementiert:

import com.octo.captcha.engine.image.ListImageCaptchaEngine;
import com.octo.captcha.service.captchastore.CaptchaStore;
import com.octo.captcha.service.captchastore.FastHashMapCaptchaStore;
import com.octo.captcha.service.image.DefaultManageableImageCaptchaService;
import com.octo.captcha.service.image.ImageCaptchaService;

/**
 *
 * @author Christoph Bünte
 *
 * @version $Revision: 1.6 $
 *
 * @created 11.10.2007
 *
 */
public class CaptchaServiceSingleton {

	private static ImageCaptchaService instance = new DefaultManageableImageCaptchaService();

	/**
	  * Gibt die einzige Instanz einnes CaptchaService zurück.
	  *
	  * @return
	  */
	 public static ImageCaptchaService getInstance() {

		return instance;
	 }
}

Im Formular für die Eingabe der Captcha Response, wird das Bild wie folgt eingebunden:

<img src="img.captcha"  class="captcha">

Je nachdem, welches Webframework man verwendet, differiert die Implementierung einer Validierungsmethode. Letztlich könnte sie wie folgt aussehen. Es ist ein Beispiel, wie es im stripes framework verwendet wird.

/**
 * Validating capture input
 *
 * @param errors
 */
@ValidationMethod(on = { "sendRecommendation" }, when = ValidationState.ALWAYS)

public void validateCaptcha(ValidationErrors errors) {
 try {
 	String sessionId = context.getRequest().getSession().getId();
 	if (!CaptchaServiceSingleton.getInstance().validateResponseForID(
 			sessionId, captchaResponse)) {
 		errors.add("captchaResponse", new LocalizableError(
 				"captchaResponse.invalidValue"));
 	}
 } catch (CaptchaServiceException e) {
 	// ungültige Session id, Fehlerbehandlung
 }
}

Das Ergebnis ist schon ganz ansehnlich. Im Formular wird mit der Default Engine ein mehr oder weniger schönes Captcha Bild erzeugt. Jedoch fällt Ästheten sofort auf, dass das Bild überhaupt nicht in das Design der Seite passt. Um solche Anforderungen zu erfüllen, implementiert man am besten eine CaptchaEngine. Dazu müssen wir die Singleton Klasse noch etwas modifizieren, doch das schnell erledigt. Wird sind doch agil, oder?

Die unten gezeigte Engine erzeugt ein Captcha Bild mit hellblauem Hintergrund und grauer und schwarzer Schrift. Für die Schrift werden nur Großbuchstaben verwendet. Man hätte als Alternative auch die Informationen zum Rendern des Bildes auch direkt in der Singleton Klasse zu einer vorhandenen Engine hinzufügen können. Unangenehmer Nebeneffekt ist aber, dass es immer eine Default engine gibt. Beim Rendern der Bilder wird dann eine verfügbare Engine zufällig ausgewählt, so dass in unregelmässigen Abständen eine Bild mit grün-rot-gelb gesprenkeltem Hintergrund erscheint. Dieses, für mich anfänglich, merkwürde Verhalten hat mich zwei Stunden aufgehalten. Wer unterschiedliche Captcha Bilder erzeugen möchte implenentiert entsprechend mehr Klassen. Hier ein Beispiel:

import java.awt.Color;import com.octo.captcha.component.image.backgroundgenerator.BackgroundGenerator;
import com.octo.captcha.component.image.backgroundgenerator.UniColorBackgroundGenerator;
import com.octo.captcha.component.image.fontgenerator.DeformedRandomFontGenerator;
import com.octo.captcha.component.image.fontgenerator.FontGenerator;
import com.octo.captcha.component.image.textpaster.RandomTextPaster;
import com.octo.captcha.component.image.textpaster.TextPaster;
import com.octo.captcha.component.image.wordtoimage.ComposedWordToImage;
import com.octo.captcha.component.image.wordtoimage.WordToImage;
import com.octo.captcha.component.word.wordgenerator.RandomWordGenerator;
import com.octo.captcha.component.word.wordgenerator.WordGenerator;
import com.octo.captcha.engine.CaptchaEngine;
import com.octo.captcha.engine.image.ListImageCaptchaEngine;
import com.octo.captcha.image.ImageCaptchaFactory;
import com.octo.captcha.image.gimpy.GimpyFactory;

/**
 * Das ist unsere spezielle {@link CaptchaEngine} Implementierung.
 * @author Christoph Bünte
 *
 * @version $Revision: 1.2 $
 *
 * @created 12.10.2007
 *
 */
final public class CustomCaptchaEngine extends ListImageCaptchaEngine {

@Override
 protected void buildInitialFactories() {

// RGB: #4C4E42
 	Color textColor = new Color(0x4c, 0x4e, 0x42);
 	Color textColor2 = Color.BLACK;
 	Color[] colors = new Color[2];
 	colors[0]=textColor;
 	colors[1]=textColor2;

// RGB: #F4F8FB
 	Color backgroundColor = new Color(0xf4, 0xf8, 0xfb);

// Einheitlicher Hintergrund mit der gegeben Breite, Höhe und Farbe
 	BackgroundGenerator bgGenerator = new UniColorBackgroundGenerator(250,
 			70, backgroundColor);

// Der Text hat die Min-und Maxlänge mit den gegeben Farben
 	TextPaster paster = new RandomTextPaster(6, 6, colors);

// Schriftgrößen 10 bis 30
 	FontGenerator fontGenerator = new DeformedRandomFontGenerator(
 			10, 30);

// Benutze einen einfachen Mechanismus zum Mischen von Hintergrund und Text
 	WordToImage wordToImage = new ComposedWordToImage(fontGenerator,
 			bgGenerator, paster);

// Benutze zufällige Worte aus den gegebenen Buchstaben
 	WordGenerator wordGenerator = new RandomWordGenerator(
 			"ABCDEFGHIJKLMNOPQRSTUVWXYZ");

ImageCaptchaFactory factory = new GimpyFactory(wordGenerator,
 			wordToImage);

 	this.addFactory(factory);
 }
}

Und hier die neue Singleton Implementierung:

import com.octo.captcha.engine.image.ListImageCaptchaEngine;
import com.octo.captcha.service.captchastore.CaptchaStore;
import com.octo.captcha.service.captchastore.FastHashMapCaptchaStore;
import com.octo.captcha.service.image.DefaultManageableImageCaptchaService;
import com.octo.captcha.service.image.ImageCaptchaService;

/**
 *
 * @author Christoph Bünte
 *
 * @version $Revision: 1.6 $
 *
 * @created 11.10.2007
 *
 */

public class CaptchaServiceSingleton {

	private static ImageCaptchaService instance = initializeService();

	/**
	  * Gibt die einzige Instanz einnes CaptchaService zurück.
	  *
	  * @return
	  */
	 public static ImageCaptchaService getInstance() {
	 	return instance;
	 }

	/**
	  * Initialisiert den {@link ImageCaptchaService}
	  *
	  * @return
	  */
	 private static ImageCaptchaService initializeService() {

	// Wir brauchen eine Instanz unser eigenen Engine
	 	ListImageCaptchaEngine engine = new CustomCaptchaEngine();

		CaptchaStore captchaStore = new FastHashMapCaptchaStore();
 		captchaStore.empty();

		ImageCaptchaService service = new DefaultManageableImageCaptchaService(
 			captchaStore, engine, 180, 100000, 75000);

		return service;

 	}

}

Kommentare und Anregungen sind wie immer willkommen. Beispiele für die kreativsten Bilder nehme ich auch gerne entgegen. Viel Spass beim ausprobieren.