Im BPM- und Integrations-Umfeld trifft man immer wieder auf folgendes Problem:

Ich muss einen Prozess testen, der sich auf angebundenen Drittsysteme (FiBu, Datenbanken, SAP System, CRM System, ...) abstützt. Nicht immer (fast nie?!?) habe ich diese Systeme zum Testen zur Verfügung. Sei es, weil ich nicht im Hause des Kunden entwickele , das Drittsystem noch garnicht existiert und selbst im Werden begriffen ist oder das Drittsystem (oder die Verbindung dahin) ist so instabil das ich nicht weiss, ob der Fehler, den ich gerade sehe, von meinem Code oder vom Drittsystem verursacht wird. Ein weiterer Grund kann sein, dass das Testen gegen das Echtsystem erhebliche Kosten verursacht. Das kann passieren, wenn ich Systeme eines anderen Unternehmens (z.B. Creditreform) nutze.

Was brauche ich:

1. Es muss möglich sein, ohne das Drittsystem physikalisch zur Verfügung zu haben, zu testen. (Stichwort: Simulation oder "Mock Service")
2. Ich muss leicht zwischen Simulation und Echtsystem umschalten können.

Punkt 2 ist relativ leicht dadurch zu erreichen, dass ich Aufrufe der Drittsysteme in eigenen Funktionen kapsele. Das gilt im Übrigen für jedes Software-System. Eine monolithische Funktion läßt sich viel schwerer testen als eine Handvoll kleine Funktionen die jeweils eine genau begrenzte Aufgabe haben. In dieser Funktion kann ich dann entweder per Konfiguration oder per Ein-/Aus-kommentieren zwischen Simulation und Echt-System umschalten. In Ruby On Rails könnte man dazu z.B. ENV['RAILS_ENV'] auswerten.

Welche Möglichkeiten habe ich nun um einen Simulations- oder "Mock"-Service zu implementieren?

1. Ich schneide die Kommunikation zwischen dem Drittsytem und meinem System mit und spiele die Antwort des Drittsystems einfach zurück ("Replay"-Simulation).
2. Ich programmiere einen Simulationsservice der halbwegs dasselbe tut wie das Drittsystem (natürlich abgespeckt). Das kann man z.B. mit Systemen machen, die irgendetwas berechnen. Beispiel: ein Service, der Preise aufgrund von Eingabeparametern berechnet.
3. Ich programmiere einen Simulationsservice, der immer dasselbe zurückliefert (evtl. konfigurierbar). Paradebeispiel hierfür sind irgendwelche Status-Abfragen.
4. Will man am eigenen Code nichts verändern müssen kann man noch versuchen die technische Schnittstelle (z.B. den SOAP-Endpoint) nachzubilden und seinen SOAP-Client darauf zugreifen zu lassen. Bei webMethods kann man dann in der Administration unter Settings->Webservice Endpoint zwischen der eigenen Implementierung und dem Echt-System umschalten.

Man muss jeweils für den aktuellen Anwendungsfall das passende aussuchen. Man sollte dabei die Komplexität des Mock-Services aber nicht übertreiben, da man sonst leicht mehr Zeit in den Test des Mock-Services investiert als in den Test der Anwendung die man eigentlich testen wollte.