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

Für Deployit, das Produkt von XebiaLabs zur automatischen Bereitstellung von Java EE-Anwendungen, entwickeln und modifizieren wir ständig Integrationen mit Middleware-Systemen wie IBM WebSphere, Oracle WebLogic und dem JBoss Application Server. Diese Integrationen sind so klein, dass sie für viele verschiedene Einsatzszenarien neu arrangiert werden können. Ein typischer Schritt, wie wir diese Integrationen nennen, wäre "WebSphere-Datenquelle erstellen" oder "WebLogic Server neu starten". Wie also testen Sie diesen Code?

Wir haben FitNesse und VMware erfolgreich für Integrationstests in unseren Einsatzszenarien eingesetzt. Aber es gab ein paar Probleme mit diesem Ansatz:

• Auf diese Weise konnten wir nur komplette Einsatzszenarien testen. Wenn wir nur einen einzelnen Schritt testen wollten, mussten wir ein Einsatzszenario erstellen, das diesen Schritt verwendete, nur um ihn testen zu können.
• Da FitNesse keine Rückmeldung gibt , während ein Test läuft, und die Schritte, ganz zu schweigen von den Einsatzszenarien, manchmal eine Weile dauern können, gab es kaum Rückmeldung über den Fortschritt.
• Es ist zwar möglich, eine FitNesse Fixture mit Eclipse zu debuggen, aber das ist nicht sehr bequem, wenn Sie eine technische Komponente wie diesen Schritt debuggen wollen.
• Um zu überprüfen, ob ein Einsatzszenario erfolgreich ausgeführt wurde, mussten wir unsere FitNesse Fixture häufig erweitern. Und während das Debuggen von zu testendem Code in FitNesse schon kompliziert genug ist, ist das Debuggen einer Fixture noch schwieriger!

Es war klar, dass wir einen anderen Ansatz brauchten, wenn wir problemlos neue Schritte entwickeln wollten.

Von FitNesse zu JUnit

Zunächst einmal haben wir beschlossen, FitNesse als Test-Framework aufzugeben. Es mag zwar ein sehr nettes Tool sein, um Benutzerakzeptanztests durchzuführen und Endbenutzern zu ermöglichen, Tests zu schreiben (oder zumindest zu verstehen), aber die technische Natur unseres Produkts sorgte bereits dafür, dass wir keine Tests für nicht-technische Endbenutzer haben würden. Zusammen mit den Problemen, die FitNesse uns bereitete, war dies Grund genug, sich mit dem allgegenwärtigen JUnit zu beschäftigen. Natürlich schreiben wir keine Unit-Tests, aber das JUnit-Framework eignet sich für jede Art von automatisierten Code-Tests. Um diese Integrationstests von den regulären JUnit-Tests zu unterscheiden, haben wir Klassennamen gewählt, die auf Itest enden. Dies stellt sicher, dass ein regulärer Maven-Build sie nicht ausführen würde. Standardmäßig führt das Surefire Plugin nur Tests aus, deren Klassenname auf Test (mit einem großen T) endet.

Grundlegender Testansatz

Der grundlegende Ansatz, der in unseren Tests verwendet wird, ist folgender:

• Bestätigen Sie, dass eine Java EE-Konfiguration (z.B. eine Datenquelle oder eine eingesetzte Anwendung) nicht existiert.
• Führen Sie den Schritt zur Erstellung der Java EE-Konfiguration aus.
• Bestätigen Sie, dass die Java EE-Konfiguration tatsächlich existiert.
• Stellen Sie sicher, dass die Eigenschaften der Java EE-Konfiguration (z.B. die URL der Datenquelle) die erwarteten Werte haben.
• Führen Sie den Schritt aus, der die Java EE-Konfiguration vernichtet.
• Bestätigen Sie, dass die Java EE-Konfiguration nicht mehr existiert.

Man könnte argumentieren, dass dieser Test eigentlich zwei Teile des Codes testet: den Erstellungsschritt und den Zerstörungsschritt. Aber ein Test für die korrekte Zerstörung der Ressource muss diese ohnehin erst einrichten. Und ein Test, der eine Ressource erstellt, muss nach sich selbst aufräumen, damit der nächste Test korrekt ausgeführt werden kann. Das bedeutet, dass die Tests davon abhängig sind, dass der vorherige Test korrekt aufgeräumt wird. Ich werde jedoch in einem späteren Blog zeigen, wie Sie dieses Problem mit VMware entschärfen können.

Sicherstellen, dass Ressourcen korrekt erstellt werden

Der schwierigste Teil dieses Ansatzes ist die Feststellung, dass eine Java EE-Konfiguration existiert (oder nicht existiert) und die erwarteten Eigenschaften hat. Dazu müssen wir die Konfiguration untersuchen. Leider erfordert jeder der drei genannten Anwendungsserver eine andere Methode, um dies zu tun.

Überprüfen der IBM WebSphere-Konfiguration

Um die IBM WebSphere-Konfiguration zu überprüfen, führen wir den Befehl wsadmin Skript aus und analysieren dann die Ausgabe, um eine Map<String,String> der Eigenschaften des Objekts zu erstellen, auf das der Containment-Pfad verweist. Wenn das Skript mit einem Exit-Code ungleich Null beendet wird, wissen wir, dass das Objekt in der Konfiguration nicht existiert.

# Kommandozeilenargumente lesen
containmentpath = sys.argv.pop(0)
# Objekt-ID nach Einschlusspfad abrufen
objectid = AdminConfig.getid(containmentpath)
wenn objectid == "":
  print "Objekt mit Einschlusspfad " + Einschlusspfad + " nicht gefunden"
  sys.exit(1)
# Objekteigenschaften drucken
print AdminConfig.show(objectid)

Prüfen der Oracle WebLogic-Konfiguration

Oracle WebLogic verfügt über ein Konzept, das dem Containment-Pfad von IBM WebSphere sehr ähnlich ist, aber es gibt keinen spezifischen Namen für dieses Konzept. Daher wird in der WLST Skript, das Sie unten sehen, nennen wir es daher auch einen Containment-Pfad. Abgesehen von der Tatsache, dass Sie sich bei WLST innerhalb des Skripts mit dem Administrationsserver verbinden müssen, während wsadmin die Verbindung auf der Grundlage seiner Befehlszeilenparameter für Sie herstellt, erledigt das Skript für WebLogic die gleiche Arbeit wie das Skript für WebSphere:

# Kommandozeilenargumente lesen
Skriptname = sys.argv.pop(0)
benutzername = sys.argv.pop(0)
Passwort = sys.argv.pop(0)
url = sys.argv.pop(0)
containmentpath = sys.argv.pop(0)
# Verbinden Sie sich mit dem WebLogic-Admin-Server.
verbinden(benutzername, passwort, url)
# Liste der Eigenschaften des Objekts
ls(containmentpath)
# Trennen Sie die Verbindung und beenden Sie
disconnect()
exit()

Prüfen der JBoss-Konfiguration

JBoss verfügt nicht über eine Python-basierte Schnittstelle für administrative Skripte, aber es gibt twiddle. Mit dem Befehl query von Twiddle können wir auf die Existenz eines MBean testen, während der Befehl get es uns ermöglicht, eine Eigenschaft eines MBean abzurufen. Es gibt keinen Befehl, um alle Eigenschaften eines MBean abzurufen, aber twiddle wird so schnell ausgeführt, dass es kein Problem ist, es mehrfach auszuführen.

Fortsetzung folgt...

Damit können wir zwar überprüfen, ob die Konfiguration korrekt erstellt wurde, aber es sagt uns immer noch nicht, ob eine Anwendung diese Konfiguration wirklich verwenden kann. Wie das geht, erkläre ich im nächsten Teil (aber ich verspreche Ihnen, dass die Serie nicht so lang wird wie die Serie über die JPA-Implementierungsmuster;-)). Und ich werde auch erklären, wie Maven und VMware in all das passen.

1. Middleware-Integrationstests mit JUnit, Maven und VMware, Teil 1
2. Middleware-Integrationstests mit JUnit, Maven und VMware, Teil 2
3. Middleware-Integrationstests mit JUnit, Maven und VMware, Teil 3