Zum Hauptinhalt springen

Contract Testing

Contract Tests sichern Schnittstellen ab – ohne das komplette System end-to-end zu testen.

Sie beantworten eine sehr praktische Frage:

Verstehen sich Consumer und Provider noch – auch nach Änderungen?

Contract Testing ist damit ein Stabilitäts- und Skalierungsinstrument: weniger Integrationsbrüche, weniger Koordination, schnellere Releases.

1. Was ist ein „Contract“?​

Ein Contract ist der vereinbarte Austausch zwischen zwei Parteien, z. B.:

  • HTTP API (Request/Response)
  • Events (Schema + Semantik)
  • gRPC/Proto
  • Message Queues

Ein Contract besteht nicht nur aus Feldern, sondern auch aus Verhalten:

  • Statuscodes / Fehlerformate
  • Required vs optional
  • Default-Werte
  • Semantik („was bedeutet status=ACTIVE?“)
  • Versionierung / Deprecation

2. Warum Contract Tests notwendig sind​

Ohne Contract Tests entstehen typische Integrationsprobleme:

  • Breaking Changes „merken“ wir erst spät (meist in E2E oder Produktion)
  • Teams müssen ständig synchronisieren („habt ihr das Feld geändert?“)
  • Integrationstests werden zu schwergewichtig und flakey
  • E2E wird als „einziger Nachweis“ missbraucht

Contract Tests sind der Mittelweg:

Mehr Sicherheit als nur Unit Tests,
deutlich günstiger und stabiler als E2E.

3. Contract Testing vs. Integration vs. E2E​

TestartPrüftTypischer ScopeHauptproblem
UnitVerhalten isolierteine KomponenteIntegration fehlt
IntegrationZusammenspiel realer TeileService + DB/HTTP/StubsSetup & Wartung
ContractSchnittstellenvertragConsumer ↔ ProviderSemantik muss klar sein
E2ESystem-Flowkomplettteuer, langsam, flakey

Merksatz:
E2E validiert „funktioniert das System?“.
Contract Tests validieren „passt der Vertrag?“.

4. Arten von Contract Testing​

4.1 Consumer-Driven Contracts (CDC)​

Der Consumer beschreibt, was er braucht:

  • welche Requests er sendet
  • welche Responses er erwartet
  • welche Felder er nutzt
  • welche Fehlerfälle relevant sind

Der Provider muss beweisen, dass er diese Erwartungen erfüllt.

Vorteil: Consumer-Sicht ist maßgeblich (realer Bedarf).
Risiko: Provider muss mehrere Consumer-Verträge erfüllen → Governance nötig.

4.2 Provider Contracts / Schema Validation​

Der Provider veröffentlicht ein Schema (z. B. OpenAPI, AsyncAPI, Proto)
und Consumer prüfen dagegen.

Vorteil: klare zentrale Spezifikation
Risiko: Spezifikation driftet von realer Nutzung weg, wenn nicht gelebt

5. Was genau testet man?​

Contract Tests testen typischerweise:

  • Payload-Struktur (Felder, Typen, optional/required)
  • Statuscodes & Fehlerformate
  • Backward Compatibility (optional fields, defaults)
  • Semantik auf Schnittstellenebene (z. B. „createdAt“ ist ISO-8601 UTC)
  • Event-Schemas inkl. Version/Type

Nicht testen sie:

  • echte End-to-End Business-Flows
  • UI-Verhalten
  • vollständige Datenkonsistenz über mehrere Systeme

6. Wo gehören Contract Tests in die Teststrategie?​

Contract Tests sind der „Stabilisator“ zwischen Teams.

Empfehlung:

  • Viele Unit Tests (Domänenlogik)
  • Gezielte Integrationstests (kritische Infrastruktur)
  • Contract Tests für alle externen Schnittstellen
  • Wenige E2E-Tests für Kernflows

Contract Tests reduzieren die Anzahl notwendiger E2E-Tests deutlich.

7. Praktische Regeln für stabile Contracts​

Regel 1: Additiv statt Breaking​

  • Neue Felder optional hinzufügen
  • Default-Werte definieren
  • Bestehende Felder nicht umdeuten

Regel 2: Fehlerformate standardisieren​

Ein einheitliches Error-Schema ist Gold wert:

  • code
  • message
  • details
  • correlationId

Regel 3: Deprecation ist ein Prozess​

Breaking Change ohne Deprecation-Phase = Integrationsvorfall.

Regel 4: Contract Ownership​

Ein Contract braucht Ownership:

  • wer veröffentlicht?
  • wer versioniert?
  • wer entscheidet Breaking Changes?

8. Tooling (Beispiele)​

Contract Testing ist Konzept, nicht Tool.

Typische Tools/Standards:

  • OpenAPI für REST
  • AsyncAPI für Events
  • Pact (Consumer-Driven Contracts)
  • Schema Registry (z. B. für Avro/JSON Schema bei Events)

Wichtiger als Tooling ist:

dass Contracts als „Produkt“ behandelt werden.

9. CI/CD Integration (Minimal)​

Consumer:

  • erzeugt Contract (Artefakt)
  • veröffentlicht ihn (Repository/Registry)

Provider:

  • zieht Contracts der Consumer
  • validiert sie in CI
  • blockiert Releases bei Breaking Changes

So wird aus „wir hoffen, es passt“ ein Gate.

10. Typische Anti-Patterns​

  • „OpenAPI existiert, aber wird nie getestet“
  • „Contract Tests prüfen nur happy path“
  • „Provider ändert Semantik, ohne Schema zu ändern“
  • „Consumer ignoriert Deprecation“
  • „Events ohne Version/Type“ (Chaos Engineering by accident)

11. Verbindung zu Qualitätsstufen​

  • Stufe 2: erste Contracts (OpenAPI), wenige Contract Checks
  • Stufe 3: Contract Tests als Standard für externe APIs
  • Stufe 4: Contracts + Traceability (Ticket → Change → Contract → Test)
  • Stufe 5: auditierbare Evidence zu Schnittstellenänderungen

Contract Testing ist ein Skalierungshebel ab Stufe 3.

Kernaussage​

Contract Testing macht Integration planbar.

Es ersetzt nicht E2E – aber es verhindert,
dass E2E zur einzigen Sicherheitsinstanz wird.

Je mehr Teams und Services, desto wichtiger sind Contracts.
Ohne Contracts skaliert nicht Software – sondern Reibung.