The document discusses consumer-driven contracts and how they facilitate service evolution and cultural change within organizations. It emphasizes the importance of agility in software architecture to respond to customer needs and introduces Pact as a tool for ensuring reliable service changes without breaking existing consumer expectations. The content also covers the advantages of using contract tests over integration tests, promoting collaboration and efficiency in service delivery.

1. Consumer Driven Contracts
Say what you mean and mean what you say
@robdcrowley
robdcrowley

2. Session Goals
Learn how consumer driven contracts facilitate a low friction
approach to service evolution
Explore how Pact enables service providers to know if a change
would break consumers before deploying
Consumer driven contracts as a catalyst for cultural change
Empower you with innovative ideas to bring back to your
organisation!

3. Digital disruption is driving change across established
industries

4. The agility to respond to rapidly changing customer
needs is vital for remaining competitive

5. Software architecture must also become more agile

6. Modern Architectures are Complex
Service
Service
Service
Service Service
Service
Service Service
Service
Service
Service
Client
Client
Client
Service
Service
Service
Service

7. Some people, when confronted with a problem, think
“I know, I'll use system integration tests.” Now their
problems scale combinatorially.

8. Combinatorial Scaling
2 code paths: 26
= 64
4 code paths: 46
= 4096
6 code paths: 66
= 46656
8 code paths: 86
= 262144
Service
Service
Service
Service Service
Service
Service
Service
Service
Service
Service
Service
Client
Client
Client

9. “Reliability problems largely occur at
module boundaries, and most result
from inconsistencies in both sides
expectations”
- Bertrand Meyer, Object Success

10. Implicit Interfaces
No explicit interface between
collaborators enforced by type
system or compiler checks
Service
Service
Service
Service Service
Service
Service
Service
Service
Service
Service
Service
Client
Client
Client

11. Implicit Interfaces
No explicit interface between
collaborators enforced by type
system or compiler checks
Let’s change and deploy a
service
Service
Service
Service
Service Service
Service
Service
Service
Service
Service
Service
Service
Client
Client
Client

12. Implicit Interfaces
No explicit interface between
collaborators enforced by type
system or compiler checks
Let’s change and deploy a
service
Hope we don’t break existing
collaborators
Service
Service
Service
Service Service
Service
Service
Service
Service
Service
Service
Service
Client
Client
Client

13. Integration Tests
Slow (longer feedback cycle)
Brittle
Difficult to manage
Finding the actual issue requires triage
Scale combinatorially
Written after the code rather than before

14. So if integration tests are not the solution
then what is?

15. So if integration tests are not the solution
then what is?
Test Symmetry

16. symmetry
s m tri/ˈ ɪ ɪ
noun
The correspondence of the form and
arrangement of elements or parts on opposite
sides of a dividing line.

17. Test Symmetry
A B

18. A B
Mock
Test Symmetry

19. A B
MockTrivial
Test Symmetry

20. A B
MockTrivial Tricky
Test Symmetry

21. Symmetrical tests have the exact opposite properties

22. Pact
www.pact.io

23. Know when you break a consumer before deploying
the change

24. Specification by Example

25. Pact – Define Expectations
Consumer Provider
PACT
HTTP Request
HTTP Response
Record

26. Pact – Verify Expectations
Consumer Provider
PACT
HTTP Request
HTTP Response
Replay

27. Fast (rapid feedback cycle)
Reliable
Low ramp up cost
Straightforward to debug
Scale linearly
Contract Tests

28. Given ”products exists”
Upon receiving ”a GET request for product catalogue”
With “an Accept header of application/hal+json”
Will respond with ”200 OK”
And “a Content-Type header of application/hal+json”
And ”the product catalogue details in the entity body”

29. Given ”products exists”
Upon receiving ”a GET request for product catalogue”
With “an Accept header of text/plain”
Will respond with ”406 Not Acceptable”

30. Given ”Widget product does not exist”
Upon receiving ”a GET request for Widget product”
Will respond with ”404 Not Found”

31. Examples

32. Joining the dots...
Product
Sales
Service
Product
Catalogue
Service
Product
Stock
Service
Pact
Broker
git clone https://github.com/robcrowley/microservices-pact-demo.git
JUnit for pact generation
Gradle pact plugin for provider
verification
Pact Broker for pact repository
Docker integration

33. Start with the consumer

38. Then move onto the provider

43. “Be liberal in what you accept, and
conservative in what you send”
- Jon Postel, The Robustness Principle

44. Implications of Postel’s Law
An expectation may not be made for a field to be absent from a
response
Exception: Request headers that change the behaviour of the
provider must be specified in expectations

45. Sharing Pacts

46. Pact Broker
Consumer Provider
Pact Broker

47. Pact Broker
Consumer Provider
Pact Broker
Publish
PUT /pacts/provider/{provider}/consumer/{consumer}/versions/{version} HTTP/1.1

48. Pact Broker
Consumer Provider
Pact Broker
Publish
PUT /pacts/provider/{provider}/consumer/{consumer}/versions/{version} HTTP/1.1
Pull
GET /pacts/provider/{provider}/consumer/{consumer}/latest HTTP/1.1

49. Facilitates the sharing of pacts between consumer
and provider projects
Enables service release cycles to be decoupled
Example driven API documentation
Visualisations of relationships between services
Web Hooks to provide integration with CI Builds
Pact Broker

52. Backwards Compatibility Testing
Use Tags to ensure provider is compatible with latest and released versions of consumers
PUT /participants/{consumer}/versions/{version}/tags/{tag} HTTP/1.1
GET /pacts/provider/{provider}/consumer/{consumer}/latest/{tag} HTTP/1.1
Consumer Head
(Pact Broker)
Consumer Production
(Pact Broker)
Provider Head
(Source Control)
Contract Tests
Contract Tests
Producer backwards
compatibility
Provider Production
(Source Control)
Contract Tests
Consumer backwards
compatibility
Already Tested

53. So once contract tests are in place I can throw all
of my integration tests away?

54. It depends on the criticality of the business capability
the service supports and your risk appetite

56. Make production monitoring and alerting a priority

57. Other Benefits

58. Higher quality services

59. “Quality comes from deliberate thought”
- Michael Feathers, Testing Patience

60. Reduced waste in delivery process

61. The business value realized by a service is defined
by the parts of it’s provider contract being leveraged
by consumers

62. “The biggest cause of failure in software-
intensive systems is not technical failure; it’s
building the wrong thing.”
- Mary Poppendieck

63. Focusing on delivering the capabilities as defined in
consumer contracts drives building the right thing

64. Takeaways
Consumer Driven Contracts enable services to evolve gracefully
Pact combines isolated unit testing with contract testing
Pact enables delivery at speed by providing rapid feedback on
potential breakages
Pact allows test driven development principles to be applied to
services
Consumer Driven Contracts can be a catalyst for cultural change by
fostering collaboration between delivery teams and reducing waste

65. “Deploying to production quickly is easy;
doing so quickly and responsibly
however is non trivial”
- Rob Crowley

66. Adopting a consumer driven contract testing
approach can help

67. Questions

68. More Info
Gitbook: docs.pact.io
Github: realestate-com-au/pact and DiUS/pact-jvm
User group: https://groups.google.com/forum/#!forum/pact-support
Twitter: pact_up
Pact to the Rescue!: http://www.slideshare.net/bethesque/pact-44565612
Deploy with Confidence using Pact Go!: https://www.youtube.com/watch?v=SMadH_ALLII
Consumer Driven Contracts – A Service Evolution Pattern: http://martinfowler.com/articles/consumerDrivenContracts.html

69. Appendices

70. Contracts 101
Provider Consumer DrivenConsumer
Closed & Complete
Singular & Authoritive
Bounded Stability &
Immutability
Open & Incomplete
Mutable & Non-Authoritive
Bounded Stability &
Immutability
Closed & Complete
Singular & Non-Authoritive
Bounded Stability &
Immutability