Microservices have become mainstream now.
We're able to respond to changing requirements and ship code to production more quickly than ever. Or, we were for our first microservice. And even our second and third.
But 5 years down the track, what happens when we end up with tens or hundreds of microservices that are now part of our core product - how do we know that we're safe to deploy to production without running hours of complex integration tests, defeating the purpose of using microservices in the first place?
Find out how contract tests can keep your microservices free from the burden of integration testing, and allow you to ship your code with speed and confidence.
4. WHAT WE ARE KNOWN FOR
4
Microservices
Solved problems New problems
● 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
8. WHAT WE ARE KNOWN FOR
8
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
25. WHAT WE ARE KNOWN FOR
25
Speed up your releases
Do less Do more
● Aggregated logging
● Metrics
● Semantic monitoring
● Alerting
● Correlation IDs
● Integration testing
ANOTHER WAY
33. 33
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
34. 34
WHEN
the provider receives
a GET request for /alligators/Mary
THEN
it will return
a 404 Not Found
response
a 200 OK
response
A CONTRACT TESTING JOURNEY
35. 35
GIVEN
<the provider is in a certain state>
WHEN
the provider receives
<some request>
THEN
it will return
<some response>
A CONTRACT TESTING JOURNEY
36. 36
You still need to think about test
data
A CONTRACT TESTING JOURNEY
37. A contract testing
journey
● Automate the contract exchange
● You still need to think about test
data
A CONTRACT TESTING JOURNEY
39. 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
A CONTRACT TESTING JOURNEY
41. 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
42. 42
The other service needs to know when a
contract has changed
You need a way to introduce changes without
breaking everything
Contracts are not a substitute for good
communication between teams
A CONTRACT TESTING JOURNEY
45. 45
Contracts are STILL not a substitute for
good communication between teams
A CONTRACT TESTING JOURNEY
46. ● 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
● You need a way to introduce
changes without breaking
everything
● Remember: contracts are not a
substitute for good communication
between teams
A contract testing
journey
A CONTRACT TESTING JOURNEY
52. 52
If you can’t deploy your services
independently,
you don’t have microservices.
You have a distributed monolith.
A CONTRACT TESTING JOURNEY
53. 53
If you can’t deploy your services
independently,
you don’t have microservices.
You have a distributed monolith.
A CONTRACT TESTING JOURNEY
Warning!
Don’t build a
distributed monolith