JUnit,ShrinkWrap und der MavenImporter

In einen unserer letzten Beiträge haben wir einen Blick auf ein Basis-Setup für das Testen von Java EE Anwendungen geworfen. Dabei haben wir die zu testende Anwendung als vollständiges WAR deployt und zwar auf Basis eines zuvor laufenden Maven-Builds. Zumindest in Eclipse (mit seinen eigenen Build-Prozess) ist das nicht die optimale Wahl.

Die Möglichkeiten das zu testende Artefakt zu bauen sind Vielfältig, vom einzelnen hinzufügen von Klassen und Packages (Aufwändig, Fehleranfällig) bis hin zum vollständigen Deployment eines WAR-Archivs (Maven Build benötigt) ist alles machbar. Eine Variante die in den aktuelleren Versionen zur Verfügung steht geht noch einen Schritt weiter: auf Basis des der pom.xml die unser Projekt ja hinreichend beschreibt ist ShrinkWrap damit in der Lage unser Archiv selbständig zusammen zu bauen ohne das explizit ein Maven-Build im Vorfeld laufen muss:

pom.xml

<dependency>
    <groupId>org.jboss.shrinkwrap.resolver</groupId>
    <artifactId>shrinkwrap-resolver-impl-maven-archive</artifactId>
    <scope>test</scope>
</dependency>

Basis-Test-Klasse

@Deployment()
public static WebArchive createDeployment() {
    File pomFile = new File("pom.xml");
    WebArchive deployment = ShrinkWrap.create(MavenImporter.class, UUID.randomUUID().toString() + "_junit-demo-test.war")
            .loadPomFromFile(pomFile)
            .importBuildOutput().as(WebArchive.class);

    deployment
            .addPackage("de.gedoplan.webclients.test")
            .addPackage("de.gedoplan.webclients.testhelper")
            .addPackage("de.gedoplan.webclients.test.dbunit")
            .addAsResource(new File("src/test/resources/dbunit_full.xml"))
            .addAsResource("test-persistence.xml", "META-INF/persistence.xml");

    return deployment;
}

Mit dieser Konfiguration ist es den Eclipse-Benutzer nun auch wieder möglich direkt auf einer Test-Klasse den entsprechenden Test aus zu führen („Run as“ > „Junit Test“) ohne das vorher ein Maven-Build gelaufen ist (NetBeans z.B. würde diesen ohnehin vorher aufrufen).

Neben dem kompletten Laden des Projektes ermöglicht der Importer  es auch nur bestimmte Abhängigkeiten zu laden und diese dem Deployment hinzuzufügen um z.B. kleinere Test-Einheiten zu generieren. Nur eine kleine Einschränkung existiert derzeit noch: das komplette Laden des Projektes wie oben gezeigt wird derzeit für EAR-Projekte nicht unterstützt.

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: