Bartlomiej Frackiewicz

Weiter aus der Serie “nützliche Unit-Test Tools”: der Apache FTP Server. Mit wenigen Zeilen Code kann man einen lokalen FTP Server starten, der dann für Tests verwendet werden kann.

Wie üblich reicht für das Einbinden vom Apache FTP Server ein Eintrag in maven:

<dependency>
    <groupId>org.apache.ftpserver</groupId>
    <artifactId>ftpserver-core</artifactId>
    <version>1.0.4</version>
</dependency>

Aus Performancegründen bietet es sich an, den FTP Server nicht generell zu speichern, sondern den Start in eine statische Methode auszulagern, sodaß pro Test entschieden werden kann, ob ein FTP Server benötigt wird.

File ftpDirectory = new File("ftproot");
ftpDirectory.mkdirs(); // create target/ftproot

FtpServerFactory serverFactory = new FtpServerFactory();
ListenerFactory factory = new ListenerFactory();
factory.setPort(2121); // FTP Port, unter Linux > 1024

try {
    serverFactory.addListener("default", factory.createListener());

    PropertiesUserManagerFactory userFactory = new PropertiesUserManagerFactory();
    File userFile = new File("ftpusers.properties");
    userFactory.setFile(userFile);
    serverFactory.setUserManager(userFactory.createUserManager());

    ftpServer = serverFactory.createServer();
    ftpServer.start();
} catch (Exception e) {
    LOGGER.log(Level.SEVERE, "Unable to start test ftpserver", e);
}

Um dann das Verhalten von Komponten zu testen, die einen FTP Up- oder Download durchführen, kann simpler Verwendung von java.io.File prüfen, ob Dateien vorhanden sind bzw. diese dann weitergehend verarbeiten.

Beispiel für das überprüfen einer hochgeladenen Datei:

assertTrue(new File(ftpDirectory, path).exists());

• Sinnvolle Plugins für Struts2 (basierend für 2.2.1.1)
  • struts2-tiles-plugin.jar
  • struts2-json-plugin.jar (für Ajax)
  • struts2-jquery-plugin-2.5.3.jar (für JQuery Integration)
• Alle Formularfelder pro Action in einer dafür entsprechenden Formular-Bean gruppieren. Dies vereinfacht die Lesbarkeit und macht die Struts2-Applikation für jemanden aus der JEE Welt deutlich lesbarer. Desweiteren lässen sich so View und Model auch für anderen Frameworks (JSF) wiederverwenden.
• Wenn Formuale vorausgefüllte Select-Boxen oder ähnliches haben sollen, dann diese in der entsprechendne prepare-Methode (siehe Preparable Interface) vorbereiten. Achtung: unbedingt: paramsPrepareParamsStack verwenden, damit auch Parameter zur Verfügung stehen.
• AJAX-Requests: das json-Plugin verwenden und den entsprechenden Result-Type “org.apache.struts2.json.JSONResult” verwenden. Weiterhin am besten ein eigenes Formular-Bean schrieben, daß aus einem Status-property und eines Ergebnis-Properties vom Typ HashMap besteht. Dies ermöglicht eine Abfrage, ob der Request generell erfolgreich war.
• Bei Validierung darauf achten, daß die zu validierende Seite über die Standard-Outcome “input” sichtbar ist. Ansonsten wird zwar validiert, aber Struts2 findet den View nicht wieder
• Weiterhin ist bei Validierung darauf zu achten, daß das UI Theme “simple” keine Feldfehler darstellt. Man muss hier nicht das Template überschreiben, sondern es reicht aus, selbstständig im entsprechenden Bereich mit dem s:fielderror den Fehler darzustellen.

Getter/Setter haben ja ihre Daseinsberechtigung, aber manchmal nervt es schon, vor allem wenn man die Entitäten per Hand schreibt und nicht generieren lässt. Ich habe gerade die Bibliothek Lombok (http://projectlombok.org) empfohlen bekommen und frage mich, warum nicht früher? Ich hätte mir so viel Tipparbeit sparen können. Mit Hilfe von verschiedenen Annotations werden Getter/Setter, aber auch Equals und Hashcode von Lombok generiert, und zwar noch in der IDE, so erscheinen Sie direkt in der Outline und können auch sofort verwendet werden. Eine Integration gibt es momentan für Eclipse und Netbeans, und die Verwendung ist auch super einfach:

@Data
public class Test {
  private long id;

  private String text;
}

ZeroTurnaround, Hersteller von JRebel, veröffentlicht auch dieses Jahr wieder seine Umfrage unter JAVA-Entwicklern über Framework, Tools und Entwicklungs-Vorgehensweisen (Redeploy, Wartezeit etc.). Sehr lesenswert!

In meinem Projekten begegne ich oft den gleichen Phänomenen: Unit-Tets sind vorhanden, aber sehr rudimentär (paar Tests für irgendwelche statischen Methoden, wenn man Glück hat werden noch Datenbankzugriffe getestet). Eine Erklärung dafür könnte sein, daß das Aufbauen eines entsprechenden Test-Environments nicht richtig durchgeführt wurde und es im Nachhinein zu komplex ist, wenn mehr als eine Datenbank benötigt wird, z. B. Testdaten müssen vorhanden sein, FTP oder E-Mailserver werden verwendet uws. Hier hat der Architekt versagt, aber auch solche Umgebungen lassen sich langsam erweitern. Dazu möchte ich hier ein paar Tools vorstellen, die ich im letzten Projekt einsetzen konnte. Wir beginnen mit Dumbster (http://quintanasoft.com/dumbster/), einem Fake Mailserver unter der Apache License 2.0.

Dumbster ist im Maven Repository und kann mittels pom.xml eingebunden werden

<dependency>
  <groupId>dumbster</groupId>
  <artifactId>dumbster</artifactId>
  <version>1.6</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>javax.mail</groupId>
  <artifactId>mail</artifactId>
  <version>1.4.3</version>
  <scope>test</scope>
</dependency>

Er wird einfach über einen Konstruktor in der setUp-Methode erstellt und dem Container (in meinem Fall JEE mit OpenEJB) mitgeteilt:

mockMailServer = SimpleSmtpServer.start(2525);

// mail resource
p.put("mail/postman", "new://Resource?type=javax.mail.Session");
p.put("mail/postman.mail.smtp.host", "localhost");
p.put("mail/postman.mail.smtp.port", "2525");
p.put("mail/postman.mail.transport.protocol", "smtp");
p.put("mail/postman.mail.smtp.auth", "false");

Entsprechende Unit-Tests könnten dann so aussehen:

... JAVA Code, der E-Mails via @Resource(name = "mail/postman") verschickt

assertEquals(3, mockMailServer.getReceivedEmailSize());
Iterator iter = mockMailServer.getReceivedEmail(); // get first email
SmtpMessage smtpMessage = (SmtpMessage) iter.next();
assertEquals("Test", smtpMessage.getHeaderValue("Subject"));
assertEquals("Test User <from@localhost>", smtpMessage.getHeaderValue("From"));
assertEquals("Hallo Welt!", smtpMessage.getBody());