Planen Sie, Ihre ESB Integrationsschicht in die Cloud zu migrieren? Oder planen Sie einfach ein Upgrade auf eine neue Version? Dann könnte dies das Richtige für Sie sein:
Wenn ich mit Kunden über dieses Thema spreche, bekomme ich oft Reaktionen wie diese:
„Wie testen Sie Ihre Integrationsabläufe/Prozesse?“
„Langweilig, konzentrieren wir uns auf die Umsetzung.“
„Warum? Weil die angeschlossenen Systeme oft nicht verfügbar sind“
„Wir haben bereits Dutzende von Integrationsströmen, warum sollte ich jetzt damit anfangen?“
„ESB Prozesse sind veraltet, es lohnt sich nicht, in Tests zu investieren.
Um ehrlich zu sein, hatte ich eine ähnliche Denkweise, als ich meine Karriere begann. Aber ich habe meine Lektion gelernt.
Vor kurzem haben wir mehrere Upgrade- und Migrationsprojekte durchgeführt. In den meisten Fällen gab es überhaupt keine Tests, als wir anfingen. Einige Kunden wollten nicht in das Schreiben von Testfällen für die bestehenden Integrationsabläufe investieren.
„Was nützt das, wenn Sie die Lösung bereits aktualisieren oder ersetzen? „
Wie Sie sich vorstellen können, wurden wir zu Beginn der Projekte oft zurückgewiesen, wenn es darum ging, Zeit und Ressourcen in Tests zu investieren. Vor allem, wenn es sich nicht um ein Upgrade, sondern um eine Migration handelte. Früher oder später konnten wir jedoch bei jedem Projekt die Vorteile erkennen.
Wenn Unternehmen in die Cloud wechseln oder einfach ein Upgrade auf eine neue Version durchführen, ist das Testen der Anwendungsintegrationsschicht ein wichtiger Schritt im Migrationsprozess. Diese Schicht ist für die Integration von Anwendungen und Diensten verantwortlich, die in verschiedenen Umgebungen gehostet werden. Es ist wichtig, sicherzustellen, dass diese Komponenten wie erwartet miteinander kommunizieren. Um eine erfolgreiche Migration zu gewährleisten, müssen sich die Ingenieure die Zeit nehmen, die Integrationsschicht gründlich zu testen.
Der Wechsel zu Infrastructure-as-Code und automatisierten Implementierungen wird zum De-facto-Standard. In unseren Projekten haben wir dies zusammen mit automatisierten Tests auf die Integrationsebene angewendet. Es wird immer ein gewisses Maß an Integrationstests und manuellen Tests erforderlich sein. Diese Tests sind jedoch in der Regel zeitaufwändig und kostspielig. Oft sind sie auch bis zu einem gewissen Grad fehleranfällig.
Daher ist es sehr wichtig, Probleme frühzeitig im Prozess zu erkennen und zu beheben. Integrationsabläufe sollten wie Programmierquellcode behandelt werden und bei jeder Änderung Tests auslösen. Klingt logisch … nichts Neues … richtig. Sie könnten sagen, dass ich nur das Offensichtliche sage, und ich widerspreche Ihnen nicht. Die Realität ist jedoch, dass diese logischen Dinge oft nicht umgesetzt werden.
Beispiel:
Das obige Beispiel löst bei jedem Commit+Push einen GitHub Actions Workflow aus. Die Integrationsabläufe werden erstellt und dann automatisch in einer containerisierten Umgebung bereitgestellt. Diese Umgebung wird als Teil des CICD-Workflows erstellt und dann bei der Ausführung der Tests verwendet.
Was ist erforderlich, um dies für Ihre Integrationsabläufe zu erreichen, und welche Faktoren tragen zum Erfolg bei:
- Datenqualität testen
- Automatisierte Testfälle
- Verspottung von verbundenen Systemen
- Testabdeckung
All diese Faktoren sind wichtig und einige sind leichter zu erreichen als andere. Wir verwenden unser eigenes Framework, um die Testdaten aus einer bestimmten Umgebung automatisch zu sammeln und zu testen. Diese Daten liegen dann bereits in einem Format vor, das für Tests und Mocking verwendet werden kann.
Die Testfälle werden dann in Java geschrieben (was bis zu einem gewissen Grad auch automatisiert werden kann, für einfache Assertions) und verwenden die gesammelten Daten wieder.
Das erwartete Ergebnis eines bestimmten Integrationsablaufschritts kann nachgebildet werden, wenn die Backend-Systeme nicht verfügbar sind. Das Framework kann das gesammelte Ergebnis des Schritts verwenden, anstatt das Backend aufzurufen. Alternativ (oder zusätzlich) können die Testfälle gegen eine bestimmte Umgebung mit erwarteten Testergebnissen pro Umgebung ausgeführt werden. Das bedeutet, dass Sie dieselben Testfälle verwenden können, aber z.B. während des Builds einige Systeme gespottet werden und dann bei einem Testlauf gegen eine höhere Umgebung keine Schritte gespottet werden. Die Testfälle bleiben unangetastet.
Sobald die Testfälle geschrieben und erfolgreich ausgeführt wurden, stellt sich die Frage: „Haben wir alles abgedeckt?“
Testabdeckungsberichte sind hier sehr hilfreich und zeigen Ihnen den Prozentsatz der Abdeckung insgesamt (pro Integrationsfluss/ESB-Prozess) und pro Testszenario.
Darüber hinaus können Sie die Daten aufschlüsseln und eine Liste der Schritte erhalten, die derzeit noch nicht getestet werden, auch nicht von aufgerufenen Unterprozessen. Das macht es einfacher, zusätzliche Testfälle zu identifizieren, die geschrieben werden müssen.
Wenn eine Änderung zu einem erfolgreichen Build (einschließlich Tests) führt, kann das Paket freigegeben und/oder bereitgestellt werden.
Niedrigere Umgebungen können automatisch über Ihre CICD-Pipeline bereitgestellt werden.
Continuous Delivery-Umgebungen mit Ansible, Jenkins/Github-Actions, GitHub & AWS sind eine großartige Kombination, um dies zu erreichen.
Es ermöglicht die reproduzierbare Erstellung von Umgebungen ohne manuelle Eingriffe.
Für höhere Umgebungen empfehlen wir, den gleichen Ansatz zu verwenden, aber die Bereitstellung mit freigegebenen Versionen manuell auszulösen. Ohne jeglichen menschlichen Eingriff auf den Servern ist dies weniger fehleranfällig und ermöglicht außerdem kürzere Durchlaufzeiten.
conapi ESB/Integration Testing Framework:
- Automatisch Test- und Mocking-Daten sammeln
- Mocking von Integrationsablaufschritten (d.h. Backend simulieren)
- Abdeckungsbericht (Prozentsatz, Liste der nicht getesteten Schritte)
- CICD bereit
- Testausgabe-Assertionen
