Wzorce MSA - Testy kontraktowe i Consumer-Driven Contract

w dniu

 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ędzieJęzyk / EkosystemUwagi
PactJava, JS, Python, .NETNajpopularniejsze narzędzie CDC
Spring Cloud ContractJavaIntegracja z Spring Boot
HoverflyHTTP proxy, języki dowolneSimulacja usług w testach
ContractTestJS, RESTLekkie 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

Komentarze

Prześlij komentarz