Collaborating with Contracts
- 3. REAL LIFE: COLLABORATION • just do it
- 4. REAL LIFE: COLLABORATION • just do it • negotiate a contract, adhere to it
- 5. REAL LIFE: CONTRACTS Provider Ice cream supplier Consumer Supermarket Contract must order 1 week in advance must pay at time of order must deliver within 3 business days product must not expire within 2 months
- 8. SERVICE
- 9. SERVICE • a reusable software component encapsulating a business function
- 10. SERVICE • a reusable software component encapsulating a business function • can be exposed over HTTP, queue, ...
- 11. ProviderConsumer
- 13. SERVICE CONTRACTS • request - response
- 14. SERVICE CONTRACTS • request - response • performance characteristics
- 15. PERSON SERVICE ProviderConsumers A B { id: 1, name: “Jane”, age: 26 }
- 16. USE CASES
- 17. CASE 1
- 18. PERSON SERVICE ProviderConsumers A B { id: 1, name: “Jane”, age: 26 } { id: 1, name: “Jane”, age: 26 } { id: 1, name: “Jane”, age: 26 }
- 19. NEW CONSUMER, NEWTROUBLE Provider Consumers A B { id: 1, name: “Jane”, age: 26 } { id: 1, name: “Jane”, age: 26 } { id: 1, name: “Jane”, age: 26 } C { id: 1, first_name: “Jane”, last_name: “Good”, age: 26 }
- 20. UPDATE PROVIDER DIRECTLY Provider Consumers A B { id: 1, first_name: “Jane”, last_name: “Good”, age: 26 } { id: 1, name: “Jane”, age: 26 } { id: 1, name: “Jane”, age: 26 } C { id: 1, first_name: “Jane”, last_name: “Good”, age: 26 }
- 21. CONSUMERS A AND B BREAKS Provider Consumers A B { id: 1, first_name: “Jane”, last_name: “Good”, age: 26 } { id: 1, name: “Jane”, age: 26 } { id: 1, name: “Jane”, age: 26 } C { id: 1, first_name: “Jane”, last_name: “Good”, age: 26 }
- 22. CONSUMER-DRIVEN CONTRACTS Provider Consumers A B C Contract A Contract B Contract C { id: 1, name: “Jane”, age: 26 } { id: 1, name: “Jane”, age: 26 } { id: 1, first_name: “Jane”, last_name: “Good”, age: 26 }
- 24. WHY ISTHIS USEFUL? • services are only useful when they are used
- 25. WHY ISTHIS USEFUL? • services are only useful when they are used • consumer-driven contracts makes consumer expectations explicit
- 27. CONSUMER-DRIVEN CONTRACTTESTS all the goodness of consumer-driven contracts and more
- 29. can be run as part of build pipeline unit contract functional deploy
- 31. AN EXAMPLE Provider Consumers A B { id: 1, first_name: “Jane”, last_name: “Good”, age: 26, friends: ... } { id: 1, name: “Jane”, age: 26 } { id: 1, name: “Jane”, age: 26 } C { id: 1, first_name: “Jane”, last_name: “Good”, age: 26 } $$$$
- 32. “Let me go through the 20-page contract to see if they mention ‘friends’...”
- 34. PLAYS WELL WITHTDD • write consumer-driven contract test for consumer C
- 35. PLAYS WELL WITHTDD • write consumer-driven contract test for consumer C • red-green-refactor: consumer side
- 36. PLAYS WELL WITHTDD • write consumer-driven contract test for consumer C • red-green-refactor: consumer side • red-green-refactor: provider side
- 37. PLAYS WELL WITHTDD • write consumer-driven contract test for consumer C • red-green-refactor: consumer side • red-green-refactor: provider side • make sure consumer-driven contract tests for consumers A and B still passes too
- 39. CASE 2
- 40. ProviderConsumer Service Boundary Provider stub testing around service boundary { id: 1, name: “Jane”, age: 26 }
- 41. ProviderConsumer Service Boundary Provider stub unit test on consumer: uses a provider stub verifies the consumer processes the stubbed response properly { id: 1, name: “Jane”, age: 26 }
- 42. ProviderConsumer Service Boundary unit test on provider: use fake consumer tests that given the right request, it returns the right response Fake consumer
- 43. ProviderConsumer Service Boundary Provider stub there could be a mismatch { id: 1, name: “Jane”, age: 26, address: ... } Fake consumer { id: 1, name: “Jane”, age: 26 }
- 44. ProviderConsumer Service Boundary Provider stub unit tests pass, but app will blow up { id: 1, name: “Jane”, age: 26, address: ... } Fake consumer { id: 1, name: “Jane”, age: 26 }
- 46. ProviderConsumer Service Boundary Provider stub both sides are verified against the same contract { id: 1, name: “Jane”, age: 26, address: ... } Fake consumer { id: 1, name: “Jane”, age: 26 } Contract
- 47. ProviderConsumer Service Boundary Provider stub write expectations from the consumer side { id: 1, name: “Jane”, age: 26, address: ... } Fake consumer { id: 1, name: “Jane”, age: 26 } Contract
- 48. ProviderConsumer Service Boundary Provider stub generate the contract { id: 1, name: “Jane”, age: 26, address: ... } Fake consumer { id: 1, name: “Jane”, age: 26 } Contract
- 49. ProviderConsumer Service Boundary Provider stub verify that the provider adheres to the same contract { id: 1, name: “Jane”, age: 26, address: ... } Fake consumer { id: 1, name: “Jane”, age: 26 } Contract fail: address is missing!
- 50. MAKING SURE PROVIDER AND CONSUMER DOTHEIR JOB
- 51. CASE 3
- 52. another teamour team a tale of 2 apps
- 53. another teamour team in the beginning was nothing
- 56. ProviderConsumer Service Boundary Provider stub consumer sends the right request { id: 1, name: “Jane”, age: 26 } Fake consumer { id: 1, name: “Jane”, age: 26 } Contract
- 57. ProviderConsumer Service Boundary Provider stub provider returns the right response { id: 1, name: “Jane”, age: 26 } Fake consumer { id: 1, name: “Jane”, age: 26 } Contract
- 58. another teamour team Service Boundary Contract this enables parallel development
- 61. ProviderConsumer Service Boundary Provider stub { id: 1, name: “Jane”, age: 26 } Fake consumer { id: 1, name: “Jane”, age: 26 }
- 62. ProviderConsumer Service Boundary Provider stub write the tests for the consumer { id: 1, name: “Jane”, age: 26 } Fake consumer { id: 1, name: “Jane”, age: 26 }
- 63. person_service. given("a person with too many friends"). upon_receiving("request for person details").
- 64. with(method: :get, path: "/person/1", query: ''). person_service. given("a person with too many friends"). upon_receiving("request for person details").
- 65. with(method: :get, path: "/person/1", query: ''). person_service. given("a person with too many friends"). upon_receiving("request for person details"). will_respond_with(status: 200, headers: {'Content-Type' => 'application/json; charset=utf-8'}, body: { id: 1, name: “Jane”, age: 26, address: ... })
- 66. with(method: :get, path: "/person/1", query: ''). person_service. given("a person with too many friends"). upon_receiving("request for person details"). will_respond_with(status: 200, headers: {'Content-Type' => 'application/json; charset=utf-8'}, body: { id: 1, name: “Jane”, age: 26, address: ... }) expect(subject.person_details(“1”)).to eq(expected_person)
- 67. ProviderConsumer Service Boundary Provider stub run watch it fail make it pass { id: 1, name: “Jane”, age: 26 } Fake consumer { id: 1, name: “Jane”, age: 26 }
- 68. ProviderConsumer Service Boundary Provider stub the consumer tests generates a “pact” { id: 1, name: “Jane”, age: 26 } Fake consumer { id: 1, name: “Jane”, age: 26 } Pact
- 69. ProviderConsumer Service Boundary Provider stub configure to verify selected pact(s) { id: 1, name: “Jane”, age: 26 } Fake consumer { id: 1, name: “Jane”, age: 26 } Pact
- 70. Provider rake pact:verify Pact controller serializer service model actual HTTP requests Fake consumer
- 71. MORE ON PACT
- 72. standalone stub Out-of-process provider stub { id: 1, name: “Jane”, age: 26 } Actual consumer
- 73. person_service. given("a person with too many friends"). upon_receiving("request for person details"). provider states given("a person with too many friends").
- 74. person_service. given("a person with too many friends"). upon_receiving("request for person details"). provider states provider_state "a person with too many friends" do set_up do 10_000.times do person = Person.first person.friends << Person.new(...) end end end
- 75. will_respond_with(status: 200, headers: {'Content-Type' => 'application/json; charset=utf-8'}, body: { id: 1, name: Pact::SomethingLike.new(“Jane”), age: 26, address: ... }) loose matching with(method: :get, path: "/person/1", query: ''). person_service. given("a person with too many friends"). upon_receiving("request for person details"). Pact::SomethingLike.new(“Jane”)
- 76. SUMMING UP
- 77. USE CASES
- 78. USE CASES • making consumer expectations explicit
- 79. USE CASES • making consumer expectations explicit • making sure both consumer and provider do their job
- 80. USE CASES • making consumer expectations explicit • making sure both consumer and provider do their job • enabling parallel development
- 81. THE DEVIL IS INTHE DETAILS
- 82. YMMV
- 84. THANKYOU