In the real world, when two parties collaborate, there often needs to be a shared understanding - a 'contract'. So is the case when two components of a system collaborate. In this talk, I will share about contract tests, when they become useful, and some tools to help.

1. COLLABORATING WITH
CONTRACTS
@stania_ang

2. REAL LIFE: COLLABORATION

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

6. MOVING ALONG...

7. COLLABORATION: SERVICES

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

12. SERVICE CONTRACTS

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
}

23. WHY ISTHIS USEFUL?

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

26. CONSUMER-DRIVEN
CONTRACTTESTS

27. CONSUMER-DRIVEN
CONTRACTTESTS
all the goodness of consumer-driven contracts and more

28. rake consumer:verify
rake provider:verify
executable

29. can be run as part of build pipeline
unit contract functional deploy

30. living documentation

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’...”

33. PLAYS WELL WITHTDD

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

38. MAKING CONSUMER
EXPECTATIONS EXPLICIT

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
}

45. HOW CAN CONTRACTTESTS
HELP?

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

54. another teamour team
Service
Boundary
Contract

55. another teamour team
Service
Boundary
Contractexecutable

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

59. ENABLING PARALLEL
DEVELOPMENT

60. TOOL: PACT
github.com/realestate-com-au/pact

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

83. SEE COLLABORATION?
THINK CONTRACTS

84. THANKYOU