Middleware-Integrationstests mit JUnit, Maven und VMware, Teil 3 (von 3)

Letztes Jahr, vor den Weihnachtsfeiertagen ;-), habe ich beschrieben, wie wir bei Xebia Middleware-Integrationstests durchführen und wie wir Testservlets bereitstellen, indem wir sie in WAR- und EAR-Dateien verpacken, die im laufenden Betrieb generiert werden. Bleibt nur noch eines zu erklären: Wie integrieren wir diese Tests in einen kontinuierlichen Build mit Maven und VMware?

Ausführen der Middleware-Integrationstests

Lassen Sie uns also mit der Maven-Konfiguration beginnen. Wie ich bereits im ersten Blog dieser Serie erwähnt habe, sind die Integrationstests daran zu erkennen, dass die Klassennamen auf Itest enden. Das bedeutet, dass sie von der Standardkonfiguration des Maven Surefire-Plugins nicht erfasst werden. Und das ist auch gut so, denn wir wollen diese Tests nicht immer ausführen. Erstens erfordern sie eine sehr spezifische Testkonfiguration (die Konfiguration des Anwendungsservers sollte sich in einem erwarteten Zustand befinden, siehe unten) und zweitens kann es lange dauern, bis sie abgeschlossen sind, was der schnellen Umsetzung, die wir von Commit-Builds in unserem kontinuierlichen Integrationssystem erwarten, im Wege stehen würde.

Wenn wir jedoch die Middleware-Integrationstests ausführen möchten, können wir das Maven Surefire-Plugin mit einem Maven-Build-Profil wie folgt konfigurieren:

<Profile>
    <Profil>
        <id>itest</id>
        <bauen>
            <Plugins>
                <Plugin>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <Konfiguration>
                        <enthält>
                            <include>**/Test*.java</include>
                            <include>**/*Test.java</include>
                            <include>**/*TestCase.java</include>
                            <include>**/*Itest.java</include>
                        </includes>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

Um die Middleware-Integrationstests zusätzlich zu den regulären Tests auszuführen, können wir Maven mit dem Flag -P anweisen, dieses Profil zu verwenden:

$ mvn -Pitest test

Wenn wir wollen, dass dieses Profil nur die Middleware-Integrationstests ausführt, müssen wir die Zeilen weglassen, die die Standardklassennamen enthalten ( Test.java, Test.java und *TestCase.java ).

Definition des erwarteten Status für die Ziel-Middleware

Eine große Herausforderung bei der Durchführung von Middleware-Integrationstests besteht darin, sicherzustellen, dass sich die Middleware, gegen die wir testen, in einem korrekten Zustand befindet. Der Test könnte zum Beispiel erwarten, dass ein Anwendungsserver-Cluster läuft, aber keine Anwendung darauf bereitgestellt wird. In einem normalen Test können wir eine Testvorrichtung in einer mit @Before markierten Methode einrichten, aber in diesem Fall ist das vielleicht nicht so einfach. Die Middleware in den erwarteten Zustand zu versetzen, wäre eine Integration für sich!

Der erste Ansatz zur Lösung dieses Problems besteht darin, alle Middleware-Integrationstests so zu schreiben, dass sie alle vorgenommenen Änderungen rückgängig machen. Ein Test, der beispielsweise eine Datenquelle erstellt, entfernt sie auch wieder. Auf diese Weise kombinieren wir den Test für den Erstellungsschritt mit dem Test für den Löschschritt. Der Nachteil dabei ist, dass diese beiden Schritte nicht mehr unabhängig voneinander getestet werden können, der Vorteil ist jedoch, dass der kombinierte Test schneller abläuft. Damit dieser Ansatz erfolgreich ist, sollten sich alle Tests, die dieselbe Ziel-Middleware verwenden, auf einen gemeinsamen erwarteten Zustand einigen. Wir konfigurieren die Ziel-Middleware einmal in diesem Zustand und alle Tests versetzen die Middleware nach Abschluss in diesen Zustand zurück. Mit einem solchen Setup können wir schnell einen oder mehrere Integrationstests ausführen, entweder interaktiv von einer IDE wie Eclipse oder von Maven aus.

Dabei gibt es jedoch ein Problem. Was ist, wenn der Test fehlschlägt? In diesem Fall wird die Middleware möglicherweise nicht im richtigen Zustand belassen. Man könnte argumentieren, dass die Schritte, die zur Rückgängigmachung der Middleware erforderlich sind, in einer @After-Methode untergebracht werden sollten, aber sie könnten trotzdem fehlschlagen. Noch wichtiger ist, dass diese Schritte auch Teil des Tests sind, so dass sie dort eigentlich nicht hingehören!

Zurücksetzen der Ziel-Middleware auf den erwarteten Zustand mit VMware

An dieser Stelle kommt VMware ins Spiel. Indem wir die Ziel-Middleware in einem Hypervisor wie VMware installieren, können wir einen Snapshot erstellen, wenn sich die Middleware im erwarteten Zustand befindet. Dann können wir zu diesem Zustand zurückkehren , bevor wir einen einzelnen Test oder eine Testsuite ausführen. Am einfachsten ist es, den Zustand vor der Ausführung der Tests manuell über die Hypervisor-Verwaltungskonsole wiederherzustellen. Aber wir können die Images auch automatisch zurücksetzen, so dass wir diese Tests in unsere kontinuierlichen Integrations-Builds integrieren können.

Die Images, die wir für unsere Middleware-Integrationstests verwenden, laufen auf VMware vSphere 4. Wir haben festgestellt, dass das vSphere SDK für Perl und insbesondere das mitgelieferte Beispielskript vmrun.pl die einfachste Möglichkeit ist, eine Schnittstelle zu VMware vSphere herzustellen. Dies ist zum Beispiel das Skript, mit dem wir unser JBoss-Image zurücksetzen:

IMAGE_NAME="[datastore1] jboss-42/CentOS 5.3, JBoss 4.2.3-GA.vmx"
SNAPSHOT_NAME="Bereit für den Test"
SETTLE_TIME=60
VMRUN=/usr/lib/vmware-vix/lib/api/vix-perl/samples/vmrun.pl
echo "VMWare-Image $IMAGE_NAME wird auf Snapshot $SNAPSHOT_NAME zurückgesetzt"
$VMRUN -host $VMWARE_HOST -Benutzername $VMWARE_USERNAME -Passwort $VMWARE_PASSWORD  
  revertToSnapshot "$IMAGE_NAME" "$SNAPSHOT_NAME"
echo "Wir warten $SETTLE_TIME Sekunden, bis sich alles beruhigt hat"
schlafen $SETTLE_TIME

Wenn Sie dieses Skript ausführen, müssen Sie die richtigen Werte für die Umgebungsvariablen VMWARE_HOST, VMWARE_USERNAME und VMWARE_PASSWORD eingeben. Nachdem das Image zurückgesetzt wurde, warten wir 60 Sekunden lang, damit sich das Image beruhigen kann. Wie viele Sekunden hier benötigt werden, lässt sich nicht genau bestimmen, aber dieser Wert ist für uns gut geeignet.

Damit Maven dieses Skript ausführt, bevor die Integrationstests ausgeführt werden, aber nur, wenn ein bestimmtes Profil ausgewählt wird, haben wir diese Konfiguration zum POM hinzugefügt:

<Profile>
    <Profil>
        <id>revert-vmware-images</id>
        <bauen>
            <Plugins>
                <Plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>exec-maven-plugin</artifactId>
                    <Version>1.1</version>
                    <Hinrichtungen>
                        <Ausführung>
                            <!-- Wir wollen wirklich, dass dies direkt vor der Testphase ausgeführt wird. -->
                            <!-- Das ist das Beste, was wir tun können. -->
                            <phase>prozess-test-ressourcen</phase>
                            <Ziele>
                                <Ziel>exec</Ziel>
                            </goals>
                        </execution>
                    </executions>
                    <Konfiguration>
                        <Ausführbar>/bin/sh</ausführbar>
                        <commandlineArgs>src/test/scripts/revert-vmware-images.sh</commandlineArgs>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

Zusammenstellen

Mit den beiden in diesem Blog vorgestellten Profilen weisen wir Maven an, die VMware-Images zurückzusetzen und alle Middleware-Integrationstests auszuführen, indem wir den folgenden Befehl eingeben:

$ mvn -Prevert-vmware-images -Pitest clean test

Wir haben unser Continuous Integration System so konfiguriert, dass es diesen Befehl einmal am Tag als sekundären Build ausführt, und es mit den richtigen Werten für die Umgebungsvariablen VMWARE_HOST, VMWARE_USERNAME und VMWARE_PASSWORD konfiguriert. Auf diese Weise verlangsamen die Middleware-Integrationstests nicht den Standard-Commit-Build (in unserem Fall dauert es etwa 90 Minuten, bis sie abgeschlossen sind!). Ein weiterer Vorteil ist, dass wir wissen, wann die VMware-Images von den Tests verwendet werden, so dass wir sie zu anderen Zeiten für manuelle Experimente nutzen können.

Fazit

In diesem Blog und in den ersten beiden Blogs dieser Serie habe ich erklärt, wie wir JUnit, Maven und VMware verwenden, um wiederholbare, verwaltbare Middleware-Integrationstests zu schreiben. Diese Tests haben uns geholfen, viel Vertrauen in die Stabilität der Middleware-Integrationen von Deployit zu gewinnen. Und da dieser testunterstützende Code Teil der Plugin-API von Deployit ist, können Entwickler von Deployit-Plugins ihn nutzen, um das gleiche Vertrauen in ihren eigenen Code zu gewinnen!