<div dir="ltr"><div class="h5">On Mon, Jun 23, 2014 at 8:46 PM, Jonathan <span dir="ltr"><<a href="mailto:j.fantham@gmail.com" target="_blank">j.fantham@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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></blockquote><div><br></div></div></div><div>An approach I have used with reasonable success on a few recent API JSON projects is the following.<br></div><div>I think it is a combination of your second and third options.<br>
</div><div><br></div><div>* setting up a apiary project that serves as documentation and as a mock server<br></div><div>* the clients (mobile, Java apps, ...) start developing and testing against the apiary mock server<br>
</div><div>* writing basic automated curl tests against that mock server (a rake task that analyzes the responses)<br></div><div>* using these `rake test:curl` tests against the Ruby development env on localhost as outer test loop<br>
</div>* developing the Ruby app with inner test loops (features/unit tests) that have more business detail<br></div><div class="gmail_quote"> (building the feature tests using the exact json that is written in the apiary spec)<br>
</div><div class="gmail_quote"><div><div>* with some care, these same `rake test:curl` tests can also be run against preprod and production<br></div><div> as a smoke test after deployment<br></div><div><br></div></div><div>
After initial set-up, the apiary spec is managed by a dedicated owner of the interface (in one case, a<br>business analyst, not a developer) that manages upgrades and versioning of the API interface definition<br>with the different stakeholders.<br>
</div><div><br></div><div>HTH,<br><br></div><div>Peter<br></div><div><a href="http://vandenabeele.com" target="_blank">http://vandenabeele.com</a><br></div></div></div></div>
</div><br><br clear="all"><br>-- <br>Peter Vandenabeele<br><a href="http://www.linkedin.com/in/petervandenabeele" target="_blank">http://www.linkedin.com/in/petervandenabeele</a><br><a href="https://github.com/petervandenabeele" target="_blank">https://github.com/petervandenabeele</a><br>
<a href="https://twitter.com/peter_v" target="_blank">https://twitter.com/peter_v</a><br>gsm: +32-478-27.40.69<br>e-mail: <a href="mailto:peter@vandenabeele.com" target="_blank">peter@vandenabeele.com</a><br>skype: peter_v_be
</div>