Skip to content

Commit 761fe7a

Browse files
authored
Update readme.md
1 parent 1e3ce5e commit 761fe7a

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

readme.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -794,7 +794,7 @@ Component tests focus on the Microservice ‘unit’, they work against the API,
794794

795795
<br/><br/>
796796

797-
## ⚪ ️2.3 Ensure new releases don’t break the API using
797+
## ⚪ ️2.3 Ensure new releases don’t break the API using contract tests
798798

799799
:white_check_mark: **Do:** So your Microservice has multiple clients, and you run multiple versions of the service for compatibility reasons (keeping everyone happy). Then you change some field and ‘boom!’, some important client who relies on this field is angry. This is the Catch-22 of the integration world: It’s very challenging for the server side to consider all the multiple client expectations — On the other hand, the clients can’t perform any testing because the server controls the release dates. [Consumer-driven contracts and the framework PACT](https://docs.pact.io/) were born to formalize this process with a very disruptive approach — not the server defines the test plan of itself rather the client defines the tests of the… server! PACT can record the client expectation and put in a shared location, “broker”, so the server can pull the expectations and run on every build using PACT library to detect broken contracts — a client expectation that is not met. By doing so, all the server-client API mismatches are caught early during build/CI and might save you a great deal of frustration
800800
<br/>

0 commit comments

Comments
 (0)