[LRUG] Fwd: Testing SOAs

Peter Vandenabeele peter at vandenabeele.com
Tue Jun 24 09:18:15 PDT 2014


On Mon, Jun 23, 2014 at 8:46 PM, Jonathan <j.fantham at gmail.com> wrote:

> Hi there,
>
> 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.
>
>  - use VCR to connect to the genuine service the first time and save a
> response
>  - create clients for your services, and use mock clients during testing,
> or stub the real clients explicitly in tests.
>  - create fake services that respond to the same interface as the real
> service but just return dummy responses (as in this talk
> https://www.youtube.com/watch?v=6mesJxUVZyI around 11:45).
>
> 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.
>
> 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?
>
>
An approach I have used with reasonable success on a few recent API JSON
projects is the following.
I think it is a combination of your second and third options.

* setting up a apiary project that serves as documentation and as a mock
server
* the clients (mobile, Java apps, ...) start developing and testing against
the apiary mock server
* writing basic automated curl tests against that mock server (a rake task
that analyzes the responses)
* using these `rake test:curl` tests against the Ruby development env on
localhost as outer test loop
* developing the Ruby app with inner test loops (features/unit tests) that
have more business detail
  (building the feature tests using the exact json that is written in the
apiary spec)
* with some care, these same `rake test:curl` tests can also be run against
preprod and production
  as a smoke test after deployment

After initial set-up, the apiary spec is managed by a dedicated owner of
the interface (in one case, a
business analyst, not a developer) that manages upgrades and versioning of
the API interface definition
with the different stakeholders.

HTH,

Peter
http://vandenabeele.com



-- 
Peter Vandenabeele
http://www.linkedin.com/in/petervandenabeele
https://github.com/petervandenabeele
https://twitter.com/peter_v
gsm: +32-478-27.40.69
e-mail: peter at vandenabeele.com
skype: peter_v_be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140624/8ad82aca/attachment.html>


More information about the Chat mailing list