http://rubyrogues.com/176-rr-rails-as-an-soa-client-with-pete-hodgson/
podcast-rr-176-rails-as-an-soa-client#likes-contract-tests1
Pete Hodgson, about 14:00 minutes in
SARON: To make sure that it works the way you think it works. And I think that's called contract tests. Can you talk a little bit about that?
PETE: Yeah. So, contract test is this idea, the challenge as you're saying where if you're testing against a fake version of the services, you're essentially testing against your understanding of how this other service works. So, because you're not actually talking to the blue team's deal service, if they change the way their deal service works or if you just misunderstand how it works in the first place and they start returning date times as seconds from the epoch rather than ISO 8601 or something like that, they change the format of their data structures or they add a field or they remove a field, you're not going to know from your fake services because your fake services are fake. They're not the real deal.
So, one of the antidotes to that is to write contract tests, and these are also sometimes described as consumer-driven contracts. And the idea there is the consumer of the service writes tests against that service that basically encapsulate what they expect that service to do. So, they're like a contract between the two. They become a contract between the two teams essentially, where the consumer of the service gives these tests to the provider of the service and says, "If you can get all these tests to pass, then as far as I'm concerned you are doing everything I need from you as a service."
So, we might write some tests that make sure that when we call the deals of the day it comes back with these values. Or if it's a login service then we write some tests where we give it some good username and password and make sure it comes back with the expected response, and a bad username and password and make sure it comes back with the expected response. So, this is a way to encapsulate a communication mechanism between the two teams where you write the tests and give them to the team and then the team knows whether the tests are working or not.
podcast-rr-176-rails-as-an-soa-client#likes-contract-tests1