Testowanie kontraktów sprawdza, czy dwie usługi zgadzają się co do ich API bez uruchamiania ich razem w pełnym teście integracyjnym. W kontraktach kierowanych konsumentem (consumer-driven contracts - CDC) konsument określa, czego potrzebuje, a dostawca weryfikuje, że może to dostarczyć.
Pełne testy end-to-end na wielu usługach są powolne, niestabilne i trudne do uruchomienia przy każdym commicie. Testy kontraktów wychwytują zmiany API, które przerywają pracę, wcześnie i w izolacji.
1. Consumer writes expectations ─▶ generates a CONTRACT (Pact file)
2. Contract published to a broker
3. Provider runs the contract against itself in its own pipeline
4. Provider build FAILS if it would break the consumer
// consumer declares exactly what it expects from the provider
provider.given('order 42 exists')
.uponReceiving('a request for order 42')
.withRequest({ method: 'GET', path: '/orders/42' })
.willRespondWith({
status: 200,
body: { id: '42', total: 99.5 } // the shape the consumer relies on
});
CI dostawcy odtwarza to i kończy się niepowodzeniem, jeśli nie zwraca już tego kształtu.
| Test kontraktu | Test integracyjny | |
|---|---|---|
| Usługi uruchomione | Po jednej | Wszystkie razem |
| Prędkość | Szybko | Powoli |
| Wychwytuje | Przerwy w kontrakcie | Rzeczywiste problemy z połączeniami |
Testy kontraktów dają ci pewność, że zmiana dostawcy nie złamie konsumentów, bez kosztów i niestabilności uruchamiania całego systemu.
Uczą niezależne wdrażanie bezpiecznym: potok każdego zespołu natychmiast wie, czy jego zmiana naruszałaby kontrakt, na którym ktoś zależy.