Pact ist ein Open Source Code-First-Tool zum Testen von https- und Nachrichtenintegrationen mithilfe von Contract Tests. Diese stellen sicher, dass die Nachrichten zwischen den Anwendungen mit einem gemeinsamen Verständnis übereinstimmen, dass in einem Contract dokumentiert ist. Die Alternative zu Contract Tests, sind Integrationstests, auf die ich in späteren Beiträgen eingehen werde. Alles in allem sind sie dafür da, um sicherzustellen, dass die Anwendungen korrekt zusammenarbeiten.
Kurze Zeitreise
Bis zum Aufkommen der Microservice-Architekturen wurde Software klassischerweise als Monolith entworfen. Dabei gab es keinerlei interne Schnittstellen, da alle Informationen im Monolithen weitergereicht werden konnten. Dementsprechend konnte man sich im Testing nur auf die Stufen Unittests, Integrationstests und End-to-End-Tests konzentrieren. Mit dem Aufkommen der Microservice-Architekturen existiert nun eine Vielzahl an internen Schnittstellen und damit entsteht die Notwendigkeit, diese zu testen. Die Kommunikation der Services untereinander geschieht dabei nicht zufällig, sondern folgt klar definierten Regeln, den sogenannten Schnittstellen-Contracts.
Was ist Contract Testing?
Wie bereits angesprochen, wurde die korrekte Zusammenarbeit von API und Consumer meist durch Integrationstests sichergestellt. Da diese allerdings eine lauffähige Systemlandschaft benötigen, können Fehler erst relativ spät erkannt werden. Bei der Entwicklung ist es jedoch von Vorteil, das Feedback so früh wie möglich zu erhalten. Hinzu kommt, dass Integrationstests eigentlich zum Prüfen der Fachlichkeit dienen. In heutigen Testlandschaften stellen sie strenggenommen „nur nebenher“ fest, wenn es technische Probleme an der Schnittstelle gibt. Das kann sowohl bedeuten, dass der Aufwand bei der Fehlersuche steigt, weil neben fachlichen Problemen auch technische Ursachen zum Fehlschlag des Tests führen können, als auch der Wartungsaufwand der Tests sich erhöht.
Macht also Sinn, dedizierte Tests zu nutzen, um Fehler an Schnittstellen zu finden. Hier bietet sich Contract Testing, genauer gesagt, Consumer Driven Contract Testing (CDCT) an. Verträge für Softwarekomponenten. Der Zusatz „Consumer Driven“ bedeutet, der Consumer bestimmt den Vertrag (Aus diesem Grund nennt man es auch Consumer Contract) und das sich die API nach dessen Vorgaben richten muss.
Neben Consumer Contracts gibt es die etwas verbreiteteren Provider Contracts wie WSDL-/XML-Schemata von SOAP-APIs oder Werkzeuge wie Swagger im Kontext von REST-Services.
Auch wenn sich die Funktionsweise von Framework zu Framework unterscheidet, bleibt die Idee dahinter gleich. Der Provider erfüllt den vom Consumer definierten Vertrag.
Der Vertrag enthält die API samt Parameter und die erwartete (minimale) Antwort. Dabei kann die Beschreibung der Parameter durch den Einsatz von regulären Ausdrücken beliebig präzise sein. So kann der Consumer erwarten, beim Aufruf der API einen unbestimmten String-Parameter oder einen bestimmten String-Parameter aus einem vordefinierten Set zu übergeben. Der zweite Fall ist äußerst hilfreich, wenn der Provider diesen String-Parameter in einen Enum-Wert übersetzt.
Der Consumer Test mit Pact
Sämtliche Verträge zwischen dem Consumer und dem Provider werden in einer JSON-Datei, auch Pact-Datei genannt, definiert. Der Consumer generiert diese Pact-Datei beim Ausführen seiner Pact-Tests und veröffentlicht sie auf dem Pact-Broker. Bei den Tests handelt es sich um gewöhnliche Unit-Tests und sie basieren auf einem der vielen von Pact unterstützen Test-Frameworks wie JUnit oder Jest. In dem Test ruft der Consumer die zu testende API inklusive Parameter auf. Der Aufruf wird von einem Mock-Provider, der vom Pact-Framework zur Verfügung gestellt wird, entgegengenommen. Der Mock-Provider prüft, ob dieser Aufruf mit dem Aufruf aus dem Vertrag übereinstimmt. Sind keine Abweichungen gefunden, antwortet der Mock-Provider mit der minimalen Antwort, die ebenfalls aus dem Vertrag stammt. Der Consumer empfängt in seinem Test die Antwort und vergleicht sie mit seiner Erwartung. Stimmen sie überein, ist der Test erfolgreich. Auf diesem Weg stellt der Pact-Test sicher, dass der Consumer den Aufruf tätigen und die Antwort verarbeiten kann.
Der Pact-Broker ist ein Webserver, der sowohl vom Consumer als auch vom Provider erreichbar sein muss. Er verwaltet die Verträge, indem er sie versioniert ablegt, sie dem Provider zur Verfügung stellt und die Testergebnisse speichert. Die Art und Weise wie der Consumer die Verträge auf dem Pact-Broker veröffentlicht, ist abhängig von der eingesetzten Programmiersprache der Tests und/oder dem eingesetzten Dependendency-Management. Für Maven beispielsweise gibt es ein spezielles Pact-Plugin, das den publish-Goal anbietet, für JavaScript existiert hingegen eine spezielle Pact-Version mit dem Namen Pact-js.
Der Provider Test
Analog zum Consumer-Test ist der Provider-Test auch ein Unit-Test und wird im Rahmen der restlichen Unit-Tests ausgeführt. Hierbei werden alle Verträge, die der Provider mit seinen Consumern abgeschlossen hat, vom Pact-Broker heruntergeladen. Der Aufruf der APIs erfolgt lokal, sodass ein Aufruf durch den Consumer simuliert wird. Der Provider verarbeitet den Aufruf und generiert seine Antwort, die mit der erwarteten Antwort aus dem Vertrag verglichen wird. Sollten sie gleich sein, hat der Provider den Pact-Test bestanden. Ansonsten gilt der Test als fehlgeschlagen und das Artefakt des Providers kann nicht ordnungsgemäß gebaut werden. Die Ursache für Fehlschläge sind in den meisten Fällen Code-Änderungen am Provider ohne den Consumer entsprechend angepasst zu haben oder die Erwartungshaltung des Consumers ist fehlerhaft. In beiden Fällen wird durch CDCT ein Missstand aufgedeckt, der erst zur Laufzeit bemerkbar gewesen wäre.
Alternativen zu Pact
Natürlich ist Pact nicht das einzige Framework zum Implementieren von CDCT, wenn auch aktuell eines der am weitesten verbreiteten. Neben Pact existieren noch ein paar weitere Möglichkeiten für das vertragsbasierte Testen wie Postman, Spring Cloud Contract Project oder Dredd, auf die ich noch in zukünftigen Beiträgen eingehen werde. Aus diesem Grund erfolgt auch das Fazit erst, wenn ich ein paar Vergleiche aufstellen kann.