mogronalol

Hi, I am the author of the blog post. The theory would be that your service is well tested enough for the produced simulation to give the majority of scenarios that you would need for tests in the consumers. I agree that perhaps there is a missing link in the consumers not knowing in advance what to call to produce certain outcomes - perhaps Hoverfly could interpret the JSON and display a contract with possible requests responses in the UI. This would be something easily understandable for a developer so they can quickly write their tests against it. Another choice would be to use something like swagger as a source for JSON rather than the service itself. This would be good for contract driven development.

I'm curious as to the use case for this, so was wondering if you could please elaborate. When you use messaging the communication is asynchronous and therefore the applications are decoupled by nature. So when testing a service like this in isolation I would assume you just need to assert that it publishes / consumes messages correctly, not needing to worry about what happens with the services on the other side of the broker. I think I am missing something?