At my work we've taken the first step in going down the road of microservices. We're in the position where we control the development of both the service and the application which uses the service.
I've read about a popular testing strategy called "Consumer-Driven Contract Testing" in which consumers communicate the expectations they have of the provider, and based on this communication, a "contract" is created, and the provider ensures that this contract is not broken after making changes.
The concept makes perfect sense, and I've read about tools such as Pact which allow this process to be automated - consumer tests mock out the real service, make a request, assume a particular response, and then run unit tests against those mocked responses; if those unit tests pass, a "Pact" file is created. The provider can then pull in the Pact file, replay the requests, and compare its response with the response the consumer was expecting. The problem is... the .NET implementation only supports JSON responses, and our service sends responses in XML (Atom items), which means that I can't check if certain fields/attributes exist; the whole response needs to match. So the provider tests will instantly break any time a property is added/removed to the response. Very brittle. And it also appears the Pact implementations for javascript and .NET have pretty much been abandoned at this point.
My question is... Given that we control development of both the consumer and the provider, would it make more sense to forgo the option of using tools like Pact in favor of manually writing unit tests in the provider test suite that verify responses are expected (eg. the provider's XML response contains the fields/properties that the consumer is expecting)? Or are there other more modern (and up-to-date) tools that will automate this whole process?
Aucun commentaire:
Enregistrer un commentaire