What contract is in consumer-driven contract testing?

Question

Consumer-Driven Contracts: A Service Evolution Pattern presents the idea of contracts verification.

But how detailed is the contract?

• Is the contract defining only a syntax of requests/responses? Like WSDL in the case of SOAP Web services.

• Or does it describes also the order of messages, i.e., the protocol? e.g.:

• Or does it define also the behaviour of a system? In other words if I send request R and system is in state S I should receive response W? For instance, if I send a request to buy two monitors and the shop has only one monitor I should get negative but when I request only one monitor I should receive a receipt?

Answer 1

At the risk of sounding sarcastic, yes and no.

The consumer and provider contracts must define the syntax of requests and responses. If there are dependencies (indicating that the service is probably rather more tightly coupled to other elements than it should be), those must also be defined.

Conceptually and ideally each request/response pair should be independent so that if you are requesting information only available to a known user of the service, the request/response definition includes requiring some authentication token in the request and data returning only if the authentication token passes validation.

Given independence of request/response pairs, the flow of a transaction is driven entirely by the consumer. To use your example of requesting quantity 2 of widget X:

• User requests 2x widget X
• Consumer requests 2x widget X
• Provider returns 2x widget X not available
• Consumer decides whether the message is a failure (hard break) or not.

A different consumer might choose to implement a different flow:

• User requests 2x widget X
• Consumer requests quantity widget X
• Provider returns 1
• Consumer notifies user that only 1x widget X can be ordered.

Both are valid consumer contracts with the same provider contract.