[char_pointer]

> What if when building a service, the pipeline also created a virtualized version of the service as an artefact?

Yes, interesting idea! I guess it does mean that there is a "testing contract" with the consumers? ie. the consumers need to know what example cases they can depend on in _their_ tests?

[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.

[char_pointer]

Thanks, mogronalol. I agree that visualisations would be useful and I think using tests to create a virtualised service definitely has merit, because it kills two birds with one stone. I like the fact that I can give my consumers/clients something that they can use to test with without having to set up or give away the real thing.

In terms of process there's a big difference with tools like Swagger though in that you have to create the tests and corresponding implementation before you can start integration testing consumers, which might be tricky if you have multiple teams working on new services. I guess this is only really a problem when you're starting out as the tests and implementation should be ready soon after.

If we just use this for testing I was also wondering if you would use this at the beginning of your project or would you add it when the test suite start slowing down?