Wzorce MSA - Testy kontraktowe i Consumer-Driven Contract

 W architekturze mikroserwisów komunikacja między usługami to chleb powszedni. Serwis A woła B, B woła C, a C czasem pyta jeszcze o coś D... I wszystko działa — do pierwszej zmiany w jednym z tych komponentów.

Zamiast "to się chyba uda", lepiej postawić na testy kontraktowe, a konkretnie na podejście Consumer-Driven Contract (CDC). To technika, która pozwala upewnić się, że komunikujące się systemy rozumieją się bez niedomówień.

Czym jest test kontraktowy?

To umowa między usługą kliencką (consumer) a usługą dostarczającą dane (provider).
Kontrakt opisuje co dokładnie oczekuje klient, a testy sprawdzają, czy dostawca spełnia te wymagania.

Nie chodzi tu o pełne testy integracyjne – tylko o weryfikację zachowania w określonych scenariuszach komunikacyjnych.

Consumer-Driven Contract (CDC) – o co chodzi?

W podejściu CDC:

1. Klient definiuje kontrakt – np. jaką strukturę odpowiedzi HTTP oczekuje po zapytaniu GET /orders/{id}.

2. Kontrakt jest zapisywany jako artefakt (np. plik .json, .yml, .pact).

3. Dostawca (provider) implementuje API, które musi spełniać oczekiwania konsumentów.

4. W CI/CD kontrakt jest weryfikowany po stronie providera, by uniknąć regresji.

Przykład (Pact)

Załóżmy, że aplikacja frontendowa (consumer) oczekuje takiej odpowiedzi z serwisu zamówień:

{
  "id": "abc123",
  "status": "DELIVERED",
  "total": 99.99
}

Konsument definiuje kontrakt:

const provider = new Pact({
  consumer: 'Frontend',
  provider: 'OrderService',
});

provider
  .given('Order exists')
  .uponReceiving('a request for order details')
  .withRequest({
    method: 'GET',
    path: '/orders/abc123',
  })
  .willRespondWith({
    status: 200,
    body: {
      id: like('abc123'),
      status: like('DELIVERED'),
      total: like(99.99),
    },
  });

📤 Kontrakt jest publikowany do brokera (np. Pactflow), a provider w swoim CI odpala testy, które go weryfikują.

Dlaczego warto?

• ✅ Zwiększasz pewność, że nie złamiesz kompatybilności

• ✅ Wcześnie wykrywasz konflikty między zespołami

• ✅ Odchudzasz testy E2E (bo nie musisz testować wszystkiego z wszystkimi)

• ✅ Automatyzujesz weryfikację zgodności API

• ✅ Ułatwiasz niezależne wdrażanie mikroserwisów

Typowe problemy bez CDC

• 🔴 Zmiana API w jednym mikroserwisie powoduje błędy w innym (niespójność)

• 🔴 Brak testów integracyjnych → produkcja testuje za nas

• 🔴 "Ale przecież dokumentacja mówiła inaczej..."

• 🔴 Trudność w wersjonowaniu i utrzymaniu API

Popularne narzędzia CDC

Narzędzie	Język / Ekosystem	Uwagi
Pact	Java, JS, Python, .NET	Najpopularniejsze narzędzie CDC
Spring Cloud Contract	Java	Integracja z Spring Boot
Hoverfly	HTTP proxy, języki dowolne	Simulacja usług w testach
ContractTest	JS, REST	Lekkie testy kontraktowe

Jak wdrożyć CDC w praktyce

1. Zdefiniuj kontrakt po stronie klienta (frontend, inny mikroserwis)

2. Publikuj kontrakt do repozytorium (broker)

3. W CI providera uruchamiaj testy weryfikujące kontrakt

4. Nie wdrażaj providerów, którzy łamią oczekiwania klientów

5. Automatyzuj ten proces w CI/CD

Podsumowanie

Testy kontraktowe i podejście CDC to must-have w ekosystemie mikroserwisów:

🔹 Gwarantują kompatybilność usług
🔹 Ułatwiają komunikację między zespołami
🔹 Wzmacniają kulturę DevOps i ciągłą integrację
🔹 Ograniczają chaos wersjonowania API