Contract-Test-Designer

Das Problem

Microservices brechen einander still. Service A aendert sein Antwortformat, und Service B entdeckt das Problem erst in Produktion. Integrationstests helfen, erfordern aber alle Services gleichzeitig, was langsam und fragil ist. Contract Testing loest dies durch Definition der erwarteten Interaktion zwischen Consumer und Provider, wobei jede Seite unabhaengig verifiziert wird.

Der Prompt

Entwirf Consumer-Driven Contract Tests fuer die folgende Service-Interaktion. Ich brauche Tests, die Breaking API-Changes vor dem Deployment erkennen, ohne dass beide Services zusammen laufen muessen.

CONSUMER-SERVICE: [den Service beschreiben, der die API aufruft]
PROVIDER-SERVICE: [den Service beschreiben, der die API bereitstellt]
INTERAKTION: [den API-Aufruf beschreiben]

TOOL: [Pact / Spring Cloud Contract / Specmatic]

Generieren:

1. **Consumer-Contract** — Erwarteten Request und Response definieren, flexible Matcher verwenden
2. **Provider-Verifikation** — Provider States einrichten und alle Consumer-Contracts verifizieren
3. **Pact-Broker-Konfiguration** — Contract-Sharing einrichten
4. **Breaking-Change-Erkennung** — Beispiele fuer brechende und nicht-brechende Aenderungen zeigen

Beispielausgabe

describe('Benutzer-API Contract', () => {
  it('soll Benutzerprofil fuer gueltige ID zurueckgeben', async () => {
    await provider.addInteraction({
      state: 'Benutzer mit ID usr_123 existiert',
      uponReceiving: 'eine Anfrage nach dem Benutzerprofil',
      withRequest: { method: 'GET', path: '/api/users/usr_123' },
      willRespondWith: {
        status: 200,
        body: {
          id: like('usr_123'),
          name: like('Maria'),
          email: term({ generate: 'maria@test.com', matcher: '.*@.*' }),
        },
      },
    });
  });
});

Wann verwenden

Wenn mehrere Teams verschiedene Services besitzen, die ueber APIs kommunizieren, bei unabhaengigem Service-Deployment oder wenn Integrationstestumgebungen unzuverlaessig sind.

Profi-Tipps

• Consumer treibt den Contract — der Consumer definiert, was er braucht, nicht was der Provider anbietet.
• Matcher statt exakter Werte verwenden — like('Maria') bedeutet “beliebiger String”, nicht woertlich “Maria”.
• Provider States testen — der Provider muss den korrekten Datenzustand vor der Verifikation einrichten.
• Contracts versionieren — can-i-deploy-Checks in CI verwenden, um Kompatibilitaet vor dem Deployment zu pruefen.