22. September 2020
3 Min.

Service Mocking oder Consumer-Driven Contract Testing?

Neben klassischen Integrationstests sind Service Mocks ein verbreiteter Ansatz zum Testen von Schnittstellenkompatibilität. In diesem Blogbeitrag will ich kurz darstellen, was das Problem mit diesem Ansatz ist und wie Consumer-Driven Contract Testing dieses Problem lösen.

Kurz ein paar Begriffserklärungen: Ein Consumer ist ein Service, der auf zusätzliche Daten angewiesen ist, um seine Arbeit zu verrichten. Ein Provider ist ein Service, der diese Daten bereitstellt.

Ein gängiges Beispiel sind zwei Services, die über eine REST-Schnittstelle kommunizieren und Daten im JSON-Format austauschen.

Aus Sicht des Software-Entwicklers stellt sich für mich die Frage: Wie kann ich die Kommunikation zwischen Consumer und Provider testen? Mein Fokus würde hier nicht auf der Netzwerk-Kommunikation liegen, sondern auf dem Format der ausgetauschten Daten. Versteht der Provider die Anfrage eines Consumers? Kann der Consumer die Antwort des Providers lesen? Dafür gibt es mehrere Ansätze.Bild zeigt klassisches Integration Testing

Im klassischen Integration Testing werden Provider und Consumer in eine gemeinsame Testumgebung ausgerollt und gemeinsam getestet. Ich kann von solchen Tests nur abraten, weil:

  • Tests laufen nicht mehr lokal, sondern über die Netzwerkverbindung zur Testumgebung. Sie sind deswegen langsamer und weniger stabil, liefern also langsamer und unzuverlässiger Feedback.
  • Tests haben eine Abhängigkeit auf den Provider, dessen Verfügbarkeit möglicherweise nicht in unserer Hand liegt. Wir können unsere Tests also nicht zu jedem beliebigen Zeitpunkt ausführen.
  • Wie sieht es aus wenn Entwickler die Tests während der Entwicklung lokal ausführen wollen? Verbinden sie sich direkt auf die Testumgebung, oder müssen sie erst die Entwicklung abschließen, bevor sie Feedback bekommen?
  • Testumgebungen und Testdaten müssen gepflegt werden.

Service Mocking

Um den direkten Aufruf des echten Providers zu vermeiden, sind Service Mocks ein geläufiger Ansatz. Service Mocks sind schnelle, lokale Simulationen, die das echte Verhalten des Providers imitieren. Wenn wir aber Schnittstellenkompatibilität zwischen Consumer und Provider sicherstellen wollen, sind Service Mocks nur ein Teil der Lösung. Ich zeige Ihnen warum:

Bild zeigt Service Mocking

Das Problem ist, dass der Mock nur die Annahmen des Consumer-Entwicklungsteams über das Verhalten des Providers widerspiegelt. Wie stellen wir aber sicher, dass das Verhalten des Mocks mit dem echten Provider übereinstimmt? Und wie werden Änderungen des Providers zurück kommuniziert und im Mock angepasst?

Wenn es keinen automatisierten Weg gibt um den Mock mit dem echten Provider zu synchronisieren, kann es sehr leicht zu falsch positiven Testergebnissen kommen, die uns in falscher Sicherheit wiegen. Die Verwendung von Service Mocks ist also wie eine „offene Tür“ – es bleibt immer die Möglichkeit Breaking Changes einzuführen.

Consumer-Driven Contract Testing

Consumer-Driven Contract Testing schließt diese Lücke. Zuerst erstellen wir Tests für den Consumer gegen einen simulierten Provider. Beim Ausführen der Tests wird zusätzlich ein Contract generiert, das explizit beschreibt welche Erwartungen der Consumer an das Verhalten des Providers hat. Dieser Contract wird an das Entwicklungsteam des Providers übergeben.

Das Provider-Team kann nun für alle eingesammelten Contracts Tests aufsetzen, um zu prüfen, ob das Verhalten des Providers den Erwartungen der Consumer entspricht. So werden nicht nur die Annahmen der Consumer über den Provider auf Korrektheit geprüft. Es wird auch sichergestellt, dass der Provider bei Änderungen an den Schnittstellen weiter kompatibel zu jedem Consumer bleibt.

Bildf Zeigt Consumer Driven Contract Testing

Consumer-Driven Contract Testing profitiert also von den Vorteilen von Service Mocks gegenüber klassischen Integrationstests und vermeidet den Nachteil, dass veraltete Annahmen zu falsch positiven Testergebnissen und trügerischer Sicherheit führen.

Mehr Details zum methodischen Vorgehen beim Consumer-Driven Contract Testing finden Sie in unserem Artikel zu „Kompatibilitätstests mit CDCs“. Eine technischere Einführung finden Sie in meinem Blog-Beitrag Introduction to Microservices Testing and Consumer Driven Contract Testing with PACT. Mehr zu unserem Beratungsangebot rund um Consumer-Driven Contracts finden Sie hier.

Bildnachweise: © Kavzov – stock.adobe.com

Artikel kommentieren