TDD introduced many improvements into the development process, but in our opinion the biggest impact relates to code design. Looking at the code from the usage perspective (by first writing an acceptance test) allows us to focus on usability rather than concrete implementation. Unfortunately, we usually rest on our laurels not trying to uplift this practice to the architecture level. This presentation will show you how you can use the Spring Cloud Contract Verifier functionality in order to have a fully automated solution to stub your HTTP / Messaging collaborators. Just by adding proper configuration, you'll surround the microservices you are testing with faked stubs that are tested against their producer, making much more realistic tests. We will write a system using the CDC approach together with Spring Boot, Spring Cloud and Spring Cloud Contract Verifier. I'll show you how easy it is to write applications that have a consumer-driven API, allowing a developer to speed up the time for writing better quality software.

1. 1
© 2016 Pivotal
Consumer Driven Contracts and
Your Microservice Architecture
Marcin Grzejszczak, @mgrzejszczak

2. 2
Spring Cloud developer at Pivotal
Working mostly on
● Spring Cloud Sleuth
● Spring Cloud Contract
● Spring Cloud Pipelines
About me
Twitter: @mgrzejszczak
Blog: http://toomuchcoding.com

3. 3
Introduction
Demo
Summary
Agenda

4. 4
What we will NOT be talking about?

5. 5
● Schema
● WSDL
● ESB
● XSD
● XSLT
What we will NOT be talking about?
THE IDEA OF SPRING CLOUD
CONTRACT IS NOT TO
INTRODUCE UNNECESSARY
COUPLING OR REPLICATE OLD
MISTAKES

6. 6
● Producer
○ service that exposes an API
● Consumer
○ service that consumes the API of the producer
● Contract
○ agreement between producer and consumer how the API will look like
● Consumer Driven Contracts
○ approach where the consumer drives the changes of the API of the producer
Introduction

7. 7
● Stub validity & reusability in the integration tests
● Nice API creation
Introduction
What problems are we trying to solve?

8. 8
Introduction
Typical situation
HTTP
CONSUMER PRODUCER

9. 9
Introduction
How to write a test for it?
HTTP
CONSUMER PRODUCER

10. 10
Introduction
How to write a test for it?
HTTP
CONSUMER PRODUCER

11. 11
Introduction
Stub validity & reusability
WE’RE ON THE CONSUMER SIDE!!
CONSUMER OWNS THE STUB
DEFINITIONS

12. 12
Introduction
Stub validity & reusability

13. 13
Introduction
Stub validity & reusability
13

14. 14
● My tests fail cause I’m shooting a request at a non existant URL
● I rewrote all my code to work with the new URL
● The unit and integration tests pass
● Now we deploy to an environment
where real integrations will take place...
Introduction
So now what?

15. 15
Introduction
Ooops...

16. 16
Stubs that were used in the build phase have nothing to do with the real API!!
Introduction
What went wrong?
HTTP
CONSUMER PRODUCER
TEST
OK
HTTP
CONSUMER PRODUCER
REALITY
WAT?!

17. 17
● Stubs reside with the consumer
● Consumer controls the stubbing process
● How are you sure that the stubs are valid?
● What if other teams want to reuse those stubs?
Introduction
Stub validity & reusability

18. 18
● It’s the consumer that uses the API
● Consumers should take part in the creation of the API of the producer
● The producer’s API change should be driven by consumers
Introduction
Nice API creation

19. 19
Introduction
Nice API creation - no cooperation results

20. 20
Introduction
Nice API creation - no cooperation results

21. 21
Demo
Potential answer
Spring Cloud Contract

22. 22
● Consumer
○ service that gets beer requests
○ has to ask another service if the client can get the beer
● Producer
○ service that checks if the client is old enough to buy beer
● Feature
○ if the user is too young - the beer will not be sold
○ otherwise the beer will be granted
Demo
What are we going to code?

23. 23
Introduction
What are we going to code?
I’m 22 give me a beer
CONSUMER PRODUCER
There you go!
Can he get the beer?
Yes!

24. 24
Introduction
What are we going to code?
I’m 17 give me a beer
CONSUMER PRODUCER
Get lost!
Can he get the beer?
No!

25. 25
Introduction
What are we going to code?
BLACK TERMINAL
BLACK IDE
CONSUMER
WHITE TERMINAL
WHITE IDE
PRODUCER

26. 26
Demo

27. 27
Summary
Consumer’s offline
work
Consumer Phase 1 Consumer Phase 2
Consumer’s switching
to online
Producer phase
Producer’s
implementing the
feature

28. 28
Summary
PRODUCER
Consumer flow 1
CONSUMER

29. 29
Summary
PRODUCER
CONSUMER
CLONES
PRODUCER
PRODUCER
CLONE
Consumer flow 1
CONSUMER

30. 30
Summary
PRODUCER CONSUMER
CONSUMER
CLONES
PRODUCER
PRODUCER
CLONE
INTERACTION
Consumer flow 1

31. 31
Summary
PRODUCER CONSUMER
PRODUCER
CLONE
INTERACTION
CONSUMER FILES
A PR
Consumer flow 1

32. 32
Summary
Consumer flow 1
starts TDD - writes the test for the feature
clones producer code to change the API locally
in the cloned producer code converts contracts into stubs and installs them locally
in the consumer code turns Stub Runner to offline mode
configures Stub Runner to download stubs of the producer
red - green - refactor on the API and tests
repeats the process until the tests are green and API acceptable
files a PR to the producer with the contract proposal

33. 33
Summary
PRODUCER
TAKES OVER THE PR
Producer flow

34. 34
Summary
PRODUCER
TAKES OVER THE PR
Producer flow
WRITES THE MISSING
IMPLEMENTATION

35. 35
Summary
PRODUCER
TAKES OVER THE PR
Producer flow
WRITES THE MISSING
IMPLEMENTATION
MERGES TO MASTER
CI UPLOADS TO NEXUS /
ARTIFACTORY

36. 36
Summary
Producer flow
takes over the PR
writes the missing implementation that will make the autogenerated tests pass
merges PR and deploys the JARs with the app and the stubs

37. 37
Summary
CONSUMER
Consumer flow 2
SWITCHES TO
ONLINE MODE
DOWNLOADS STUBS OF
COLLABORATORS DURING
BUILD PHASE

38. 38
Summary
Consumer flow 2
switches off the Stub Runner’s offline mode once the producer uploads the stubs
configure Stub Runner by providing the URL to a repo with stubs
will have its test broken if the producer makes any breaking changes of the API

39. 39
I don’t want to keep my contracts with the producer

40. 40
Common repo with contracts - consumer
PRODUCER CONSUMER

41. 41
Common repo with contracts - consumer
PRODUCER CONSUMER
REPO WITH
CONTRACTS

42. 42
Common repo with contracts - consumer
PRODUCER CONSUMER
REPO WITH
CONTRACTS
G
IT
C
LO
N
E
CLONED REPO
WITH
CONTRACTS

43. 43
Common repo with contracts - consumer
PRODUCER CONSUMER
REPO WITH
CONTRACTS
G
IT
C
LO
N
E
CLONED REPO
WITH
CONTRACTS
INTERACTION

44. 44
Common repo with contracts - consumer
PRODUCER CONSUMER
REPO WITH
CONTRACTS
CLONED REPO
WITH
CONTRACTSPR

45. 45
Common repo with contracts - producer
PRODUCER CONSUMER
REPO WITH
CONTRACTS

46. 46
Common repo with contracts - producer
PRODUCER CONSUMER
REPO WITH
CONTRACTS
CLONED REPO
WITH
CONTRACTS
PR
O
D
U
C
ER
TAKES
O
VER
PR

47. 47
WRITES THE MISSING
IMPLEMENTATION
Common repo with contracts - producer
PRODUCER CONSUMER
REPO WITH
CONTRACTS
CLONED REPO
WITH
CONTRACTS
PR
O
D
U
C
ER
TAKES
O
VER
PR

48. 48
WRITES THE MISSING
IMPLEMENTATION
Common repo with contracts - producer
PRODUCER CONSUMER
REPO WITH
CONTRACTS
CLONED REPO
WITH
CONTRACTS
M
ER
G
E
PR

49. 49
WRITES THE MISSING
IMPLEMENTATION
Common repo with contracts - producer
PRODUCER CONSUMER
REPO WITH
CONTRACTS
CI UPLOADS TO NEXUS
/ ARTIFACTORY

50. 50
Sometimes, due to e.g. security reasons, you don’t have access to the producer’s code.
Then you can use a shared repo with contracts:
● that repo is built by your CI and produces a JAR with contract defintions
● the producer downloads the JAR with contracts and finds his contract definitions
either via convention or by provided property
● the producer creates tests and stubs from aforementioned contracts
● the producer deploys a fat JAR and JAR with stubs once the autogenerated tests pass
● the consumer via Stub Runner downloads the stubs from Nexus or can manually
create stubs from the shared repo for offline work
I don’t want to keep my contracts with the producer

51. 51
With Spring Cloud Contract and Consumer Driven Contracts:
● we’ve created an API that suits the consumer and the producer
● expectations were defined by readable contracts
● expectations were tested against the producer
● producer stubs can be reused by consumers
● starting and setting stubs is fully automated
Summary

52. 52
Why use Spring Cloud Contract Verifier?
● Possibility to do CDC with messaging
● Clear and easy to use, statically typed DSL
● Automatic generation of tests from the defined Contract
● Stub Runner functionality - the stubs are automatically downloaded at runtime from
Nexus / Artifactory
● Spring Cloud integration - no discovery service is needed for integration tests
● Integration with Cloud Foundry - Stub Runner Boot
Summary

53. 53
QUESTIONS

54. 54
Learn More. Stay Connected.
▪ Read the docs
▪ Check the samples
▪ Talk to us on Gitter
Twitter: twitter.com/springcentral
YouTube: spring.io/video
LinkedIn: spring.io/linkedin
Google Plus: spring.io/gplus

55. 55
mgrzejszczak