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());

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());