Das Problem des automatisierten Testens von EAI-Anwendungen

Um den reibungslosen Einsatz im produktiven Umfeld sicherzustellen, ist bei EAI-Anwendungen ein ausreichender Integrationstest entscheidend. Zum einen gilt es, die definierten Qualitätsziele zu erreichen, zum anderen, die Anwendung reibungslos von der Entwicklung in die Produktion zu überführen. Hierfür ist neben einer guten Testabdeckung im Unit- und Component-Test ein Integrationstest nötig, welcher primär die Schnittstellen zu anderen Systemen und die Anwendungsfälle im Ganzen absichert. Idealerweise beginnen die Tests zur Integrationsfähigkeit in die Systemlandschaft bereits während der Entwicklung – und nicht erst im Anschluss. Wenn der Test automatisiert ist und kontinuierlich erfolgt, kann der Tester jederzeit eine Aussage zum Zustand der Stabilität treffen. Automatisierte Integrationstests bilden dabei Testfälle ab, die sowohl Idealbedingungen als auch Fehlerfälle repräsentieren. Sie stellen komplette Anwendungsfälle nach und repräsentieren somit die Anforderungen der Fachabteilungen.

Integrationstests bei EAI-Anwendungen stellen den Tester jedoch vor einige schwere Probleme. Um den Nachrichtenfluss während des Tests am Leben zu halten, müssen alle Schnittstellenpartner entsprechend simuliert werden. Dies ist keine leichte Aufgabe, da es eine Vielzahl von Möglichkeiten des Schnittstellendesigns gibt. Unterschiedliche Protokolle und Technologien sowie die Anbindung von Legacy-Systemen sind somit die Quelle einer Vielzahl von Problemen für den automatisierten Test. Der Tester hat in vielen Fällen nur mehr oder weniger intelligente Stub-Implementierungen der Schnittstellenpartner zur Verfügung und muss während des Tests manuell eingreifen. Eine automatisierte Verifikation der gesendeten und empfangenen Nachrichteninhalte bleibt dabei auch auf der Strecke. Der Tester muss die Nachrichten selbst aufbereiten und die Validierung der Nachrichteninhalte ebenfalls manuell erledigen. Das ist zeitaufwändig, fehleranfällig und oftmals kein wiederholbarer Vorgang.

Qualitativ unterschiedliche Simulatoren, sowie veraltete, unvollständige oder gänzlich fehlende Stub-Implementierungen bedeuten dann das endgültige K.O. für einen automatisierten Integrationstest. Aus Zeitgründen ist es keine Seltenheit, dass der Tester nur exemplarisch einen Anwendungsfall manuell testen kann. Auf Grund der vielen Regressionstests ist es in der Praxis zudem häufig der Fall, dass bei einer neuen Softwareversion kein vollständiger Integrationstest durchgeführt wird und nur die "Problemfelder"erneut getestet werden. Eine Aussage über den Systemtestzustand ist daher nur bedingt möglich. Im schlimmsten Fall wird die Integration erst bei der Produktivschaltung der Software verifiziert.

Anforderungen an ein Testframework

Mit diesen Problemen im Integrationstest hatte auch das Softwareentwicklungshaus ConSol* (vgl. hier) bei der Abwicklung von EAI-Projekten zu kämpfen. Der Wunsch nach einem Testframework für den Integrationstest, welches einen Anwendungsfall komplett automatisiert zu testen vermag und in den Entwicklungsprozess integriert werden kann, wurde immer größer. Folgende Anforderungen bestanden an das Framework:

• Protokollabdeckung: Das Framework muss mehrere Protokolle unterstützen (JMS, SOAP, HTTP, TCP/IP etc.). Nur mit einer möglichst kompletten Protokollabdeckung ist es realistisch, eine EAI-Anwendung mit einem einzigen Framework testen zu können. Zumindest sollte das Framework die Möglichkeit bieten, Erweiterungen in Form von eigenen Adaptern zu schreiben, um weitere Protokolle zu unterstützen.
• Nachrichtenvalidierung: Jede Nachricht soll sowohl syntaktisch – bei XML über Dokumenttypdefinition (DTD) oder XML-Schema-Definition (XSD) – als auch semantisch gegen eine vom Tester erwartete Nachricht validiert werden können. Die Validierung soll an zentraler Stelle stattfinden, sodass eine fehlgeschlagene Validierung den Abbruch des kompletten Testfalls zur Folge hat.
• Dynamische Inhalte: Das Framework muss in der Lage sein, simulierte Antwortnachrichten mit dynamischen Inhalten auszustatten. Gerade bei generierten Identifikatoren (z.B. MessageID, CorrelationID vgl. Gregor Hohpe, Bobby Woolf, Enterprise Integration Patterns, Addison-Wesley]) ist dies essenziell, um das korrekte Verhalten von Schnittstellenpartnern zu simulieren.
• Lesbarkeit der Tests: Die Testfälle sollen in einem lesbaren Format in einer einzigen Datei definiert sein (Testfallbeschreibung). Auch die Fachabteilung soll den Testfall ohne große Einarbeitungszeit erstellen und nachvollziehen können. Die Lesbarkeit ergibt sich dabei aus einer domänenspezifischen Sprache (Domain Specific Language, DSL).
• Steuerung/Überwachung des Nachrichtenflusses: Innerhalb eines Anwendungsfalls werden die Nachrichten in einer meist bekannten Reihenfolge an die jeweiligen Schnittstellenpartner versendet und von diesen empfangen. Eine ausbleibende Nachricht oder eine Veränderung der Nachrichtensequenz stellt in vielen Fällen bereits eine schwerwiegende Verletzung der Sachlichkeit dar. Das Framework muss ein solches Fehlverhalten registrieren und validieren können. Daher muss die Nachrichtenfolge innerhalb des Testfalls definiert werden.

Diese Anforderungen waren Grund genug, ein eigenes Framework zu entwickeln. Neben der Protokollvielfalt stand auch die Erweiterbarkeit um eigene Testaktionen und Nachrichtenvalidatoren im Vordergrund. Die Flexibilität und Plattformunabhängigkeit von Citrus ermöglicht es, übergreifend über Technologien, Plattformen und Protokolle einen Testschirm zu spannen.