
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 23 Jun 2014, at 19:46, Jonathan <<a href="mailto:j.fantham@gmail.com">j.fantham@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi there,<div><br></div><div>I'd like to know if any of you have any advice for testing Service Oriented Architectures. Specifically the mocking of boundaries between services. Each team I've worked with in a SOA environment has a different approach to the way they isolate their services from each other for testing. E.g.</div>

<div><br></div><div> - use VCR to connect to the genuine service the first time and save a response</div><div> - create clients for your services, and use mock clients during testing, or stub the real clients explicitly in tests.</div>

<div> - create fake services that respond to the same interface as the real service but just return dummy responses (as in this talk <a href="https://www.youtube.com/watch?v=6mesJxUVZyI">https://www.youtube.com/watch?v=6mesJxUVZyI</a> around 11:45).</div>

<div><br></div><div>Each one seems to have its problems. The first is probably my preferred but I'm encountering some resistance to using it. The second and third are basically the same thing at a different level, and when I've seen these approaches used I've noticed they usually get very complicated. On occasion I've seen them end up with their own test suite.</div>

<div><br></div><div>How do you go about mocking out the interfaces between services in your projects so that test suites can run in isolation? Do you use anything different to what I've just mentioned?</div><div><br></div>

<div>Thanks!</div><div>Jono.</div></div></blockquote><br></div><div><br></div><div>Steve Smith has proposed several ideas around handling customer driven contracts between a service and its clients</div><div> </div><div><a href="http://www.alwaysagileconsulting.com/application-pattern-api-examples/">http://www.alwaysagileconsulting.com/application-pattern-api-examples/</a></div><div><br></div><div><a href="http://www.alwaysagileconsulting.com/application-pattern-consumer-driven-contracts/">http://www.alwaysagileconsulting.com/application-pattern-consumer-driven-contracts/<br></a></div></body></html>