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.

1. 1
Microservices.
Test smarter, not harder.
Beth Skurrie (DiUS)
@bethesque
#VoxxedAus2019

2. A big problem

3. Problem:
Long time to market

4. Microservices!

5. Solved a problem!
New problem...

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

7. 7
@bethesque
To E2E test, or not to E2E test?
A STORY

8. 8
@bethesque
What if there was another way?

9. 9
C P
mock
ANOTHER WAY @bethesque
Consumer tests Provider tests
Integration test

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

11. 11
C P
mock
ANOTHER WAY @bethesque

12. 12
C P
mock
ANOTHER WAY @bethesque

13. PPCC
mock
contract
ANOTHER WAY @bethesque
Consumer tests Provider tests
Integration test

14. 14
Message Contract
OTHER TOOLS
C P
contract
@bethesque

15. WHAT WE ARE KNOWN FOR
15
Contracts
Solved problems New problems
● ???● Keeping tests in sync
ANOTHER WAY @bethesque

16. How long between writing the
code and finding the bug?

17. Local
tests
Isolated CI
tests
Deploy E2E
tests
5 mins 15 mins 45 mins 1 hour +
Find
bug
here!
Not
here!
@bethesque

18. Find integration bugs
early and quickly
Contracts tests
ANOTHER WAY @bethesque

19. Know before you
commit
Contracts tests
ANOTHER WAY @bethesque

20. Make changes with
speed and confidence
Contracts tests
ANOTHER WAY @bethesque

21. Deploy independently
Contracts tests
ANOTHER WAY @bethesque

22. Better API design
(Consumer)
Contracts tests
ANOTHER WAY @bethesque

23. Are not functional tests
Contracts tests
ANOTHER WAY @bethesque

24. Are not an API
specification
Contracts tests
ANOTHER WAY @bethesque

25. Are not good for “public”
APIs (many, unknown
consumers)
(Consumer)
Contracts tests
ANOTHER WAY @bethesque

26. Are not a silver bullet!
Contracts tests
ANOTHER WAY @bethesque

27. 27
@bethesque
Business value
Code correctness

28. 28
@bethesque
The Testing Pyramid of Hell

29. 29
@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

31. My contract
testing journey

32. 32
@bethesque
● Open source
● Multiple languages
○ JVM
○ .NET
○ Javascript
○ Python
○ Go
○ + more
pact.io
● HTTP contracts
● Message contracts

33. 33
A B
mock
C P
contract
A CONTRACT TESTING JOURNEY @bethesque

34. 34
A CONTRACT TESTING JOURNEY @bethesque

35. 35
@bethesque
Too many microservices?
You need another microservice!
A CONTRACT TESTING JOURNEY

36. 36
Pact Broker
A CONTRACT TESTING JOURNEY @bethesque

37. 37
@bethesque
Problem 1: Contract exchange
Solution: Pact Broker
A CONTRACT TESTING JOURNEY

38. 38
@bethesque
WHEN
the provider receives
<some request>
THEN
it will return
<some response>
A CONTRACT TESTING JOURNEY

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

40. 40
@bethesque
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

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

42. 42
@bethesque
Problem 2: Data setup, code coverage
Solution: Provider states
A CONTRACT TESTING JOURNEY

43. A contract testing
journey
● Automate the contract exchange
● You still need to think about test
data
A CONTRACT TESTING JOURNEY @bethesque

44. 44
@bethesque
Problem 3: brittle tests
A CONTRACT TESTING JOURNEY

45. 45
@bethesque
Problem 3: brittle tests
Solution: flexible matching
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

47. 47
@bethesque
Problem 4: Dealing with
contract changes
A CONTRACT TESTING JOURNEY

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

49. 49
@bethesque
Pact Broker webhooks
A CONTRACT TESTING JOURNEY

50. 50
@bethesque
Contracts are STILL 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

52. 52
A CONTRACT TESTING JOURNEY @bethesque

53. 53
@bethesque
Problem 5: Communicating
verification results back to
consumer
A CONTRACT TESTING JOURNEY

54. 54
@bethesque
Pact Broker verifications
A CONTRACT TESTING JOURNEY

55. 55
@bethesqueA CONTRACT TESTING JOURNEY

56. 56
@bethesqueA CONTRACT TESTING JOURNEY

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

60. 60
Consumer
version
Provider
version
Verification
result
11 54 success
12 54 failure
12 55 success
13 56 success
13 57 failure
“The Matrix”
A CONTRACT TESTING JOURNEY @bethesque

61. 61
Consumer
version
Provider
version
Verification
result
11 ✓ 54 PROD. success
12 54 failure
12 55 success
13 56 success
13 57 unknown
Can I deploy?
A CONTRACT TESTING JOURNEY @bethesque

62. 62
A CONTRACT TESTING JOURNEY @bethesque

63. 63
A CONTRACT TESTING JOURNEY @bethesque

64. 64
@bethesque
What about Swagger/OAS?
OTHER TOOLS

65. 65
Provider contracts
OTHER TOOLS @bethesque

66. 66
Consumer contracts
OTHER TOOLS @bethesque

67. 67
A B
mock/write
C P
pact swagger
verify
verify
Pact+Swagger
OTHER TOOLS @bethesque

68. ● OAS support
● Improved Broker workflow
What are the next
problems to
solve for
Pact?
ANOTHER WAY @bethesque

69. WHAT WE ARE KNOWN FOR
69
Contracts
Solved problems New problems
● ???● Shipping code faster
@bethesque

70. 70
pact.io
pactflow.io
slack.pact.io
@pact_up
Microservices.
Test smarter, not harder
Beth Skurrie (DiUS)
@bethesque
#VoxxedAus2019