“Therefore test, who wants to bind himself forever”

Source: Martin Fowler, Ian Robinson: Consumer-Driven Contracts: A Service Evolution Pattern

Bind forever? Schiller is talking in his “Song of the Bell” about the bond of marriage, and assumes this is a lifelong bond. Nowadays, it is more common to talk about “marriage contracts”, so the above would read as “therefore test, who wants to subscribe a contract”.

And I guess, that is exactly what you do when you do “consumer driven contract testing”. Well, here the comparison falls a bit short – I hope that there are no consumers and providers in the context of a marriage…

So, what is this consumer driven contract testing all about? The essential idea is, that, if all consumers of a service can tell exactly what they need, the service provider only needs to fulfill exactly the requested.

Martin Fowler and Ian Robinson have already in 2006 defined a service evolution pattern outlining what needs to be done in order to mitigate coupling issues between services. The idea is, that all sets of expectations of the consumers in total lead to a complete picture of what the provider needs to fulfil. These, the provider needs to assert. Both together lead to a contractual situation between consumer and provider that can be used as a basis for further tests.


Now it is 2017. Why do I write about CDCT 11 years after?

Obviously as the topic still gives room for discussions.

In context of a master’s thesis, a colleague of mine had been evaluating the use of consumer driven contracts in context of E2E business process testing. One of her conclusions is that the consumer driven contracts are extremely likely to help the famous ice-cream cone prevented:

–          If consumer driven contracts exist and can be tested in parallel to standard integration testing, at least all technical integration issues can be tested upfront

–          Business integration issues can be reduced if the services are cut using approaches like domain driven design, where the services are aligned to business functionality. Already the discussion between consumer and the provider in order to define the tests help finding potential issues early. If the contracts could be designed from an end user centric view this could be complete – but then they still would need to be transferred to a technical implementation

–          The more services you have, the more complex would be a coverage just using business process test due to the many interfaces.

–          Having a possibility to test for the contract automatically does improve the changeability of the software, as it already gives more reliability

Assuming that the transformation of business expectations into consumer contracts is complete enough, the number of business process driven e2e tests can be reduced. However, the effort of defining the contracts seems to be most promising, if

–          The architecture is created in such a way that many independent services exist

–          Provided services have several known consumers that in total will cover all functionality

–          There is a need of having short release cycles with a highly automated test coverage and little time for E2E testing

Due to the complexity of defining the contracts and implementing the consumer driven contract tests, it was not possible to have in scope of the thesis to prove a cost reduction. While one always needs to check, if additional tests further “left” are beneficial or do lead to an “overweight” test I would conclude that at least the thought process behind defining these contracts results into the minimum needed software to be implemented and thus avoids waste. Also, the e2e tester would be freed to work in a more explorative approach, focusing on whether the software fulfils his needs. On the other hand, as with all automated tests, late changes in software do lead to an increased cost of maintenance for software and tests.


And here I would love your contribution

So far the theory. But even in above promising situations, is the main benefit of consumer driven contract testing only the thought process, or do we really save costs?

Do you have any examples or studies available?


Leave a Reply

Your email address will not be published. Required fields are marked *