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

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