Java EE im Test – Junit, DBUnit, Arquillian, Jailer

junit_title.png

Testen ist ein leidiges Thema: kaum jemand schreibt sie gerne, jeder weiß das sie notwendig sind und alle freuen sich wenn es welche gibt. Dabei ist es auch in einer Java EE Umgebung gar nicht schwer die Grundlage fürs Testen zu legen.

Arquillian

Arquillian ist ein Test-Framework das es uns erlaubt die Anwendung innerhalb des Containers zu testen. Anders als „einfache“ Junit Tests laufen also auch unsere Testfälle innerhalb unseres ApplicationServers. Das hat den entscheiden Vorteil das alle Infrastruktur-Dienste auch in unseren Tests zur Verfügung stehen: Datenbankzugriffe, Transaktionshandling und CDI Injection? Kein Problem! Dabei ist Arquillian nicht an Junit gebunden, sondern bietet auch Unterstützung für TestNG. Da in unserem Beispiel Junit zum Einsatz kommt sieht unser Maven pom.xml wie folgt aus:

<!--Junit als Basis für unsere Tests-->
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>test</scope>
</dependency>

<!-- Arquillian JUnit Integration -->
<dependency>
    <groupId>org.jboss.arquillian.junit</groupId>
    <artifactId>arquillian-junit-container</artifactId>
    <scope>test</scope>
</dependency>

<!-- Verbindung zum ApplicationServer -->
<dependency>
    <groupId>org.wildfly.arquillian</groupId>
    <artifactId>wildfly-arquillian-container-managed</artifactId>
    <version>1.1.0.Final</version>
    <scope>test</scope>
</dependency>

Neben Junit selbst und die zugehörige Integration mit Arquillian deklarieren wir noch einen Konnektor der dafür Sorge trägt wie unsere Tests später ihren Weg auf den ApplicationServer finden. Diese Konnektoren existieren für diverse Application Server in aller Regel in 3 unterschiedlichen Ausführung

  • embedded, Arquillian startet einen eigenen ApplicationServer mit festgelegter Konfiguration
  • remote, Arquillian deployt die Anwendung auf einen entfernt laufenden Server
  • managed, Arquillan deployt die Anwendung auf einen lokal bereits laufenden Server

Bevor unsere Tests nun ausgeführt werden, muss nun dafür gesorgt werden das Arquillian die Anwendung für unsere Tests bereit stellt. Der erste Schritt dazu ist unseren Test mit „@RunWith(Arquillian.class)“ zu annotieren damit Arquillian sich dieser Tests annimmt. Nun benötigen wir das eigentliche Deployment unserer Anwendung. Dazu setzt Arquillian auf „ShrinkWrap“ um dynamische Archive zu bauen auf dessen Basis die Tests statt finden. Damit haben wir die Möglichkeit nur dediziert Teile zu deployen die für unseren aktuellen Test benötigt werden. Dabei ist allerdings darauf zu achten das  auch wirklich alle abhängigen Klassen zusätzlich hinzufügt werden und auch die Deskriptoren müssen enthalten sein. Eine charmante Variante dagegen ist es das bereits gebaute Archiv unserer Anwendung zu verwenden und anschließend nur noch die nötigen Manipulationen durchzuführen (z.B. CDI Alternativen aktivieren oder die Datasource zu ändern). Die Vorbereitung eines solchen Archivs geschieht in einer Methode die mittels „@Deployment()“ annotiert ist.

@Deployment()
public static WebArchive createDeployment() {
    WebArchive deployment = ShrinkWrap
            .create(WebArchive.class, "junit-demo-test.war")
            .as(ZipImporter.class)
            .importFrom(new File("target/junit-demo.war"))
            .as(WebArchive.class)
            .addPackage("de.gedoplan.webclients.test")

    deployment.delete("META-INF/persistence.xml");
    deployment.addAsResource("test-persistence.xml", "META-INF/persistence.xml");

    return deployment;
}

Es bietet sich an eine solche Methode in eine Basisklassen aus zu lagern, sodass unser konkreter Test wie folgt aussieht:

@RunWith(Arquillian.class)
public class CustomerServiceTest extends TestBaseClass {

    @Inject
    CustomerService service;

    @Test
    public void calculateCustomerDiscount() {
        Assert.assertTrue(service.calculateCustomerDiscount("ALFAA").getDiscount() == 2.5);
    }
}

Hier ist gut zu sehen wie einfach dann ein konkreter Testfall ist. Da unser Test auf dem Server abläuft können wir CDI nutzen um direkt unsere Services zu injizieren und unsere Tests zu schreiben.

Alles auf Anfang, DBUnit

Eine Herausforderung bei den oben gesehenen Tests sind die Daten. Da wir mit einem echten Datenbestand arbeiten auf den wir auch schreibend zugreifen ist es anzuraten  einen festen Testdatenbestand bereit zu stellen. Diese Daten sollten nicht nur für konkrete Tests verändert werden können, sondern sollten vor allem Konstant bei jedem Test in gleicher Art und Weise zur Verfügung steht. Hier auf die „normale“ Testdatenbank zu setzen wird in aller Regel dazu führen das regelmäßig Tests aufgrund von geänderter Testdaten Fehlschlagen. DBUnit ist dabei ein etablierter Kandidat der auf eine XML-Datenbeschreibung setzt um Datenbanken in einen festgelegten Zustand zu versetzen. Eine solche Struktur beschreibt dann die konkreten Tabellen (shippers, categories…) und die Werte der entsprechenden Tabellenspalten (ShipperID, CategoryName…)

<dataset>
  <shippers ShipperID="1" CompanyName="Speedy Express" Phone="(503) 555-9831"/>
  <shippers ShipperID="2" CompanyName="United Package" Phone="(503) 555-3199"/>
  <shippers ShipperID="3" CompanyName="Federal Shipping" Phone="(503) 555-9931"/>

  <categories CategoryID="1" CategoryName="Beverages" Description="Soft drinks, coffees, teas, beers, and ales" Picture="beverages.gif"/>
  <categories CategoryID="2" CategoryName="Condiments" Description="Sweet and savory sauces, relishes, spreads, and seasonings" Picture="condiments.gif"/>
  <categories CategoryID="3" CategoryName="Confections" Description="Desserts, candies, and sweet breads" Picture="confections.gif"/>
</dataset>

Einen solchen Datenbestand können wir dann zu Beginn jeden Testes bereitstellen

@Before
public void initData() throws Exception {
    //Verbindung aufbauen
    Class driverClass = Class.forName("org.h2.Driver");
    Connection jdbcConnection = DriverManager.getConnection("jdbc:h2:~/junit;AUTO_SERVER=TRUE", "sa", "sa");

    //Datenladen
    InputStream inputStream = this.getClass().getClassLoader().getResourceAsStream("dbunit_full.xml");
    IDataSet dataset = new FlatXmlDataSet(inputStream);

    //Datenbank füllen
    DatabaseOperation.CLEAN_INSERT.execute(jdbcConnection, dataset);
}

(komplettes Beispiel)

Im obigen Beispiel verwenden wir aus gutem Grund eine separate H2-Datenbank. Mittels „CLEAN_INSERT“ veranlassen wir DBUnit dazu alle bestehenden Daten zu löschen. Das ist die beste Grundlage für valide Tests, sollte allerdings nicht mit der „echten“ Testdatenbank durchgeführt werden (! dazu passend müssen wir natürlich auch die test-persistence.xml anpassen die wir oben für unser Deployment erzeugen und mit ShrinkWrap installieren)

Wunde Finger? Testdaten mit Jailer

Die oben verwendeten Testdaten müssen natürlich nicht von Hand geschrieben werden. DBUnit bietet hierfür eine sehr einfache API an um bestehenden Datenbanktabellen in ein solches Format zu übertragen (DatabaseExportSample.java). Hier können wir festlegen ob eine komplette Datenbank exportiert oder selektiv nur benötige Tabelle ausgewertet werden sollen. Eine noch schönere Variante ist die Verwendung eines zusätzlichen Tools: „Jailer“. Jailer bietet uns die Möglichkeit sehr Feingranulat die Daten aus zu wählen, welche für wir exportieren wollen. Gerade bei sehr großen Datenbeständen will man als ersten Stand in aller Regel nur eine überschaubare Anzahl von Testdaten haben. Dafür bietet Jailer entsprechende Selektionskriterien und ermittelt selbstständig die benötigten Relationen (die bei Bedarf auch individuell deaktiviert werden können). Im unteren Beispiel selektieren wir z.B. ausgehenden von einer geringen Anzahl an Bestellungen alle abhängigen Daten, unterbinden aber bestimmte Relationen, wie z.B. customers > orders um die Datenmenge gering zu halten.

junit_jailer

Wie wir gesehen haben sind Tests im Java EE Umfeld kein Hexenwerk. DBUnit, Jailer, Arquillian und Junit bietet optimale Voraussetzungen um Tests zu schreiben. Allerdings bleibt es dabei: Schreiben müssen wir die Tests weiterhin selber.

Beispiel Projekt mit erweiterten Beispielen wie JAAS / RoleAllowed Testing und Maven Setup:

https://github.com/GEDOPLAN/junit-demo

Advertisements

Über Dominik Mathmann
Dominik Mathmann arbeitet als Berater, Entwickler und Trainer bei der GEDOPLAN GmbH. Auf Basis seiner langjährigen Erfahrung in der Implementierung von Java-EE-Anwendungen leitet er Seminare, hält Vorträge und unterstützt Kunden bei der Konzeption und Realisierung von Webanwendungen vom Backend bis zum Frontend. Sein derzeitiger Schwerpunkt liegt dabei auf der Entwicklung von JSF-Anwendungen. Er sieht die stärker werdende Position von JavaScript-Frameworks jedoch positiv und beschäftigt sich darüber hinaus mit Webframeworks wie AngularJS.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: