Contract Testing: Integrationen testen ohne Staging-Hölle.
Contract Testing: Integrationen testen, ohne Staging-Abhängigkeiten
Wenn zwei Teams voneinander abhängige Systeme bauen, brauchen sie einen Mechanismus, der Inkompatibilitäten früh erkennt.
Das Problem mit Integration Tests
Klassische Integration Tests laufen gegen eine Staging-Umgebung. Das hat Probleme: Staging-Umgebungen sind oft instabil, teuer zu betreiben, und nicht immer verfügbar. Wenn der Integration Test fehlschlägt – war das der eigene Code oder die Staging-Umgebung?
Contract Testing als Alternative
Consumer-Driven Contract Testing: Der API-Consumer definiert, welche Requests er stellt und welche Responses er erwartet. Diese "Contracts" werden mit dem Provider geteilt. Der Provider verifiziert, dass er die Contracts erfüllt – ohne dass Consumer und Provider gleichzeitig laufen müssen.
Tool der Wahl: Pact. Open Source, für viele Sprachen verfügbar.
Wie Pact funktioniert
- Consumer schreibt Tests, die die API aufrufen und Erwartungen definieren. Pact generiert daraus eine Pact-Datei (JSON).
- Pact-Datei wird geteilt (Pact Broker oder PactFlow für gehostete Variante).
- Provider lädt die Pact-Datei und verifiziert, dass sein API die Contracts erfüllt.
Wenn der Provider einen Breaking Change einführt, schlägt die Verifikation an – bevor das in Staging deployed wird.
Wann Contract Testing besonders wertvoll ist
Mehrere Teams, die unabhängig an ihren Services entwickeln. Microservices-Architekturen. Wenn Staging-Umgebungen ein Bottleneck sind.
Checkliste Contract Testing
Pact (oder ähnliches Tool) evaluiert
Consumer-seitige Pact-Tests für kritische Integrationen
Pact Broker eingerichtet (lokal oder gehostet)
Provider-Verifikation in CI integriert
Breaking-Change-Alert konfiguriert
Contract Testing in euer Projekt einführen?
markom.digital hilft bei der Einführung von Contract Testing – von der Tool-Auswahl bis zur CI-Integration.