Microservices have become mainstream now. Writing and deploying small, independent services has many benefits, but on the downside, it increases the number of integration points, which increases the amount of integration testing required. How can we be confident that all our services will work correctly together, without being burdened by increasingly complex and brittle integration tests? Learn how Pact solves this problem by using consumer driven contracts, allowing you to escape Integration Testing Hell and ship your code with speed and confidence.
6. WHAT WE ARE KNOWN FOR
6
Microservices
Solved problems New problems
● E2E integration tests
○ Slow tests
○ Easy to break
○ Hard to fix
○ Scale badly
○ Lots of set up
○ Flakey tests ignored
○ Takes dev time away
from features
● Feature time to market
A STORY @bethesque
10. WHAT WE ARE KNOWN FOR
10
Test symmetry
Solved problems New problems
● Hard to keep both sides in
sync
● Fast feedback
● Few dependencies
● No dedicated environment
● Reliable
● Easy to debug
ANOTHER WAY @bethesque
30. WHAT WE ARE KNOWN FOR
30
Speed up your releases
Do less Do more
● Contract testing
● Aggregated logging
● Metrics
● Semantic monitoring
● Alerting
● Correlation IDs
● Integration testing
ANOTHER WAY @bethesque
39. 39
@bethesque
WHEN
the provider receives
a GET request for /alligators/Mary
THEN
it will return
a 200 OK response
with a JSON body {“name”: “Mary”}
A CONTRACT TESTING JOURNEY
41. 41
@bethesque
GIVEN
<the provider is in a certain state>
WHEN
the provider receives
<some request>
THEN
it will return
<some response>
A CONTRACT TESTING JOURNEY
46. A contract testing
journey
● Automate the contract exchange
● You still need to think about test data
● Contracts should focus on the
messages, not the technology
● Contracts should be as flexible as
possible - but no more
A CONTRACT TESTING JOURNEY @bethesque
48. 48
@bethesque
The other service needs to know when a
contract has changed
Contracts are not a substitute for good
communication between teams
A CONTRACT TESTING JOURNEY
51. ● Automate the contract exchange
● You still need to think about test data
● Contracts should focus on the
messages, not the technology
● Contracts should be as flexible as
possible - but no more
● The provider needs to know when a
contract has changed
● Remember: contracts are not a
substitute for good communication
between teams
A contract testing
journey
A CONTRACT TESTING JOURNEY @bethesque
57. 57
@bethesque
If you can’t deploy your services
independently,
you don’t have microservices.
You have a distributed monolith.
A CONTRACT TESTING JOURNEY
Contract
tests
E2E
tests
58. 58
@bethesque
If you can’t deploy your services
independently,
you don’t have microservices.
You have a distributed monolith.
A CONTRACT TESTING JOURNEY
59. 59
@bethesque
If you can’t deploy your services
independently,
you don’t have microservices.
You have a distributed monolith.
A CONTRACT TESTING JOURNEY
Warning!
Do not build a
distributed monolith