Testgetriebene Entwicklung mit Unit-Tests ist ein besonders im agilen Umfeld häufig anzutreffendes Vorgehen. Dabei werden Unit-Tests immer parallel zur eigentlichen Komponente entwickelt. Die Komponente und der Test wachsen dann gemeinsam in kurzen Iterationen. Erst wird der Test für ein Feature entwickelt, danach das Feature, bis es den Test besteht. Dann folgt der Test für das nächste Feature.

Wie dieses Vorgehen auch bei der Implementierung automatisierter Prozesse in einer Process-Engine funktionieren kann, soll dieser Beitrag zeigen.

Alles Attrappe!

Eine große Hilfe bei testgetriebenem Vorgehen sind Mock-Objekte, die es erlauben, Funktionalität zu simulieren, die für den Test eines Features nötig, aber noch nicht fertig implementiert ist. Außerdem ermöglichen Mock-Objekte das isolierte Testen von Funktionalitäten unabhängig von anderen, die im Rahmen des Tests nicht mitgetestet werden sollen. Ein Beispiel: Ein Business-Service, der getestet werden soll, verwendet andere Business- und Domain-Services einer SOA. Für die benutzten Services existieren bereits Unit-Tests, es gibt also keinen Grund, die Funktionalität dieser Services mit zu testen. Die Services werden „gemocked“, zur Testlaufzeit werden sie nicht aufgerufen, sondern es wird nur ein vorher am Mock-Objekt definiertes Ergebnis zurückgeliefert. Das hat viele Vorteile: Steht ein aufgerufener Service einmal nicht zur Verfügung, beeinflusst das den Test nicht, es müssen z.B. keine eventuell aufwändigen Datenkonstellationen für die aufgerufenen Services erzeugt werden.

Für die Entwicklung mit Java und JUnit gibt es dafür gute und akzeptierte Frameworks, ein Beispiel hierfür ist Mockito.

TDD in der Prozessentwicklung

Schwieriger ist das testgetriebene Entwickeln, wenn es um die Automatisierung von Prozessen in einer Process-Engine geht. Viele Process-Engines nutzen für die Modellierung ausführbarer Prozesse eine eigene Notation. Frameworks, die eine testgetriebene Entwicklung unterstützen, gibt es in aller Regel nicht. Gerade die Prozessschicht, die nur Business-Services orchestriert, ist also darauf angewiesen, dass alle aufgerufenen Komponenten zur Verfügung stehen, um den Prozess testen zu können. So kann die Implementierung der Prozesse oft erst dann beginnen, wenn die Entwicklung der Services abgeschlossen ist. Agiles, iteratives Vorgehen ist dann auf dieser Ebene nur schwer möglich.

Um diesem Problem zu begegnen, haben wir in unserem laufenden Projekt ein Framework entwickelt, das uns an dieser Stelle gezielt hilft. Das Framework ist zwar in der spezifischen Notation der im Projekt eingesetzten Process-Engine implementiert, die Idee ist aber übertragbar.

Schematische Darstellen der Funktionsweise des Mock-Frameworks

Kernstück des Mocks ist eine Datenbank, in der alle für den Testlauf relevanten Informationen abgelegt werden: welcher Prozess gestartet werden soll, ob einzelne Prozessschritte gemocked oder tatsächlich ausgeführt werden und welche Response ein Mock zurückliefern soll. Dafür stellt das Mock-Framework einen Webservice-Endpoint zur Verfügung, alle Informationen werden in der SOAP-Nachricht verpackt. Das Framework parst die SOAP-Nachricht, schreibt die Mock-Informationen in die Datenbank und startet dann den angeforderten Prozess.

Mocken einzelner Services

Implementierung eines Service-Mock

Um zur Laufzeit dann einzelne Schritte mocken zu können, muss für jeden Service ein Mock-Prozess bereit gestellt werden. Dieser Prozess stellt einen Webservice-Endpoint bereit, auf den die Aufrufe aus den Fachprozessen zielen. Der Mock-Prozess ermittelt dann in der Datenbank, wie mit dem konkreten Aufruf zu verfahren ist – wird er gemocked, liest er die Response und liefert diese direkt zurück. Soll der Service aufgerufen werden, so wird der tatsächliche Endpoint angesprochen und dessen Response dann an den Fachprozess durchgereicht.

Das klappt mit Services ohne größeren Aufwand, da dort sowieso über Webservice-Calls kommuniziert wird. Beim Deployment auf die nächsthöhere Staging-Stufe wird bei den Service-Calls in den Fachprozessen der Endpoint des Mock-Frameworks durch den des echten Service ersetzt, es entsteht kein zusätzlicher Aufwand und es ist nicht nötig, das komplette Mock-Framework mit zu stagen.

Und ganze Prozesse?

Implementierung eines Subprozess-Mock

Subprozesse werden nicht per Webservice aufgerufen, sondern sind direkt in den darüber liegenden Prozess eingebettet. Dadurch kann nicht einfach ein Webservice-Call auf das Framework umgebogen werden. Soll ein Subprozess gemocked werden, muss daher ein künstlicher Aufruf des Mock-Frameworks eingebaut werden. Das Mock-Framework liefert dann die definierte Response zurück. Subprozesse lassen sich auf diese einfach als Ganzes mocken. Ist der Subprozess implementiert, muss der künstliche Aufruf des Mock-Frameworks wieder entfernt werden. Einzelne Services im Subprozess lassen sich dann wieder gezielt mocken.

Fazit

Diese relativ einfache Implementierung eines Mock-Frameworks ermöglicht uns, die Entwicklung der Prozesse schon parallel zur Entwicklung der Services zu beginnen – oder, wenn nötig, schon davor. Das lässt sich nicht nur hervorragend mit unserem agilen Vorgehen vereinbaren, es trägt auch zur Akzeptanzbildung bei. So waren wir schon im zweiten Entwicklungssprint in der Lage, den Top-Level-Prozess in der „Happy-Path“-Variante fertig zu stellen, größtenteils mit gemockten Services und Subprozessen, an geeigneten Stellen den vertikalen Durchstich zu erproben und das Ganze dann im Review erfolgreich zu präsentieren.