In welchen Umgebungen kann ich Logic-Apps testen?
Eine Logic-App (Standard) kann auf zwei ähnliche Arten getestet werden. Mit einem lokalen Test über eine Entwicklungsumgebung (Visual Studio) oder um einen automatisierten Test, welcher über eine CI/CD-Pipeline vorgenommen wird. Hierbei wird lediglich auf die CI/CD-Implementation eingegangen. Das Vorgehen für den lokalen Test ist allerdings sehr ähnlich aufgebaut.
Wie laufen Tests von Logic-Apps in einer Pipeline ab?
Die Testautomatisierung sorgt dafür, dass alle Logic-Apps lokal innerhalb der Pipeline getestet werden können, bevor diese auf Azure selbst deployt werden. Hierfür bieten Tools die Möglichkeit die Logic-App lokal, anhand der mitgelieferten Workflows und Konfigurationen, auszuführen. Diese Logic-App kann anschließend mit Hilfe eines Test-Frameworks angestoßen und ausgelesen werden.
Was wird benötigt, um eine Logic-App zu testen?
Die Pipeline muss für jeden Durchlauf vorbereitet werden, sodass sämtliche notwendigen Komponenten innerhalb der Pipeline installiert werden. Zunächst muss entschieden werden, ob die Connections der Logic-App, also beispielsweise ein verwendeter Storage-Account emuliert werden soll, oder ob ein tatsächlicher Storage Account verwendet werden soll. Nachfolgend werden alle möglichen Emulatoren vorgestellt.
- Azurite
Azurite ist ein Speicheremulator, der eine lokale Verwendung eines Storage-Accounts erlaubt. Es wird je ein Service angeboten für BlobStorage, Queues und Tables.
- Cosmos Emulator
Der Comsos Emulator folgt demselben Prinzip wie Azurite. Hierbei wird allerdings lediglich eine ComsosDB emuliert. Hierbei wird ebenfalls ein lokaler Service angeboten und über einen statischen ConnectionString bereitgestellt.
- Azure Functions Core Tools
Azure Functions Core Tools können Logic- und Function-Apps unter Verwendung der vollständigen Runtime auf dem lokalen Computer ausgeführt werden. Dies gilt auch für Pipelines.
Wie wird die Test-Automatisierung in der Pipeline implementiert?
Zunächst ist zu sagen, dass die Installation der einzelnen Komponenten innerhalb der Pipeline einige Zeit in Anspruch nehmen kann. Hierbei wurden in verschiedenen Tests Download- und Installationszeiten von bis zu 20 Minuten pro Durchlauf wahrgenommen. Es empfiehlt sich also, einen eigenen Agent zu erstellen, welcher bereits sämtliche notwendigen Komponenten vorinstalliert hat, um diese in der Pipeline verwenden kann. Dies reduziert die Durchlaufzeit und die damit einhergehende Effizienz deutlich.
Dieses Snippet zeigt die notwendigen Schritte, um Azurite, Azure Functions Core Tools und den Comsos Emulator herunterzuladen, zu installieren und anschließend auszuführen. Zudem wird eine Testplattform für Visual Studio installiert, welche für die Ausführung der Unit-Test zuständig ist. Nach der Vorbereitung der Pipeline folgt die Vorbereitung des zu testenden Codes.
Der zu testende Code muss zunächst gebaut werden. Der Code beinhaltet sowohl das Test-Framework, als auch die implementierten Tests für die zu testenden Logic-Apps. Diese Tests werden, wie gewöhnliche Unit-Tests mit dem MSTest-Testframework entwickelt. Diese Tests werden von dem Task “VSTest@2“ innerhalb der Pipeline ausgeführt. Der Test wird in eine DLL gebaut, welche im genannten Task angegeben werden muss. In dieser befinden sich sämtliche durchzuführenden Tests. Es ist zu beachten, dass sämtliche angegebenen Tasks für die Installation und Ausführung innerhalb desselben Pipeline-Jobs durchzuführen sind.
Wenn alle Tests erfolgreich durchgelaufen sind, kann die Pipeline mit dem Deployment fortsetzen. Anderenfalls schlägt das Deployment an dieser Stelle fehl. Das Ergebnis kann innerhalb des DevOps-Portals betrachtet werden.
Wie werden Tests für eine Logic-App entwickelt?
Zusätzlich liefert Microsoft ein eigenes Test-Framework für Logic-Apps. Dieses Framework erlaubt dem Anwender den ausgewählten Workflow über die Azure Functions Core Tools zu starten und einige Informationen aus diesem Workflow auszulesen.
In diesem Code-Snippet wird eine Workflow-Datei geladen und in das Testframework gegeben. Anschließend kann der Workflow gestartet werden. Die Startweise hängt vom verwendeten Trigger ab. Hierbei werden von Microsoft lediglich die „BuildIn“-Trigger der Logic-App Standard unterstützt. In diesem Beispiel wird ein HTTP-Trigger durch das Absetzen eines Request getriggert. Die Response des Workflow-Starts enthält ebenso eine Uri, welche für Status-Abfragen verwendet werden kann.
Es können allerdings keine Asserts innerhalb einzelner Workflow-Schritte gesetzt werden, da der Workflow asynchron durchgeführt wird. Es ist lediglich möglich den Status nach Workflow-Ende abzufragen. Zudem können beispielsweise CosmosDb-Einträge oder ServiceBus-Nachrichten ausgelesen werden, welche innerhalb des Workflows abgesetzt werden, sodass ein weiteres Level der Überprüfung erreicht werden kann.
Das Testframework sowie einige Beispiele können aus folgendem Github-Repositiory heruntergeladen werden. https://github.com/Azure/logicapps/tree/master/LogicAppsSampleTestFramework
Diese Tests können mit Hilfe geeigneter Emulatoren als reine Unit-Tests durchgeführt werden, bei dem der reine Logic-App-Workflow betrachtet werden kann, ohne auf äußere Einflüsse Rücksicht nehmen zu müssen. Zudem ist es möglich Integration-Tests in das Gesamtsystem durchzuführen, indem echte Connections verwendet werden. Dies erlaubt beispielsweise die Überprüfung, ob ein Datentransfer nach einem Update immer noch einem gewissen Schema entspricht. Ebenso kann die reine Verbindung einer API-Connection, uvm. getestet werden.
Diese Test-Automatisierung liefert eine mögliche Lösung, um das anfänglich diskutierte Problem der Testbarkeit einer Low-Code-Anwendung zu minimieren. Dies kann eine deutliche Qualitätssteigerung und Fehlerreduktion mit sich bringen.
Dieser quiTeq-Tipp kommt aus Stuttgart.