[LRUG] Testing SOAs

[Mark Burns]

I'd vote for the second approach.

A drawback for the VCR approach is that any change/new requirement in the
client of one _HTTP_ service results in needing the server for that service
building first, effectively eliminating any of the productivity benefits
that can come from parallelising the workload. It also helps you to plan
out your app/new features more easily, if you are only thinking in terms of
PORO for your required responses. Thinking in terms of your domain is
easier/ closer to solving the problem than thinking in terms of specific
JSON/XML responses.

I stressed HTTP for a reason. The VCR approach also ties you to a
synchronous HTTP architecture, whereas a plain ruby library makes it easier
to switch out the backend, e.g. to something like RabbitMQ. Although
practically, you're probably not likely to have written any client code to
be able to easily jump to being async, it does at least make the change
feasible.

The complexity you mention of the second/third approaches are IMHO probably
almost inevitable. Choosing SOA is making a decision to move towards a more
complex architecture for its flexibility. As with any development, software
tends to expand out in a fractal like fashion, with each part having
similarities to the system as a whole. Programs can be single liners,
multi-line scripts, scripts with includes to break into files, scripts that
use methods to break down complexity, programs that use classes to break
apart functionality, and for SOA - programs that communicate with other
programs.

Each part is approximately related to how much the average programmer can
hold in his/her head. For SOA, we're just choosing another point to break
apart complexity, so that the pieces can be simpler in and of themselves,
but as with most simplification, it still introduces complexity at the
boundary points. As with any testing, having well tested components tested
at the right level internally makes them more stable and easier to rely on.
Testing the integration between components is somewhat of an art form, that
will always eventually come down to choosing an arbitrary amount of
combinations at different levels until you feel confident that things work.

Testing at an integration level, be that functional testing like
traditional Rails-style controller testing, or any other non-isolated unit
testing, or integration of two different services, or full-stack system
tests that hit development replications of the whole system, or
browser-based tests that hit staging servers as a user might, or production
tests that actually run against production as a health-check, is always
going to be about striking a balance. It should be a feedback loop too,
making sure to not run too many tests that make the idea of deployment seem
impossible because you can never get a full build to work with every single
service before some other changes break the build. If the development cycle
makes it too difficult to get a change into production before other changes
break things again then it probably means you have either too much slow
system testing and not enough confidence in the internal services
themselves, or the boundary between services was not accurately decided and
there's too much coupling between them.

The only real generic advice I can give on testing SOAs would be to avoid
too many full system tests or testing at the rather arbitrary HTTP border
like WebMock does. Getting enough confidence in your services themselves
should be important.
I wrote a blog post recently which is kind of related:
http://blog.polyglotsoftware.co.uk/blog/2014/02/07/a-pattern-for-stubbing-out-apis-with-rspec/


On 24 June 2014 04:58, Jon Wood <jon at ninjagiraffes.co.uk> wrote:

> My experience so far in moving to an SOA from a big Rails monolith is that
> you probably need to find a balance between stubbed clients and running
> requests through the entire stack.
>
> When unit testing, and for initial smoke tests on the integration side,
> stubbing out responses works well to keep things moving quickly enough to
> give yourself a level of confidence, but that doesn't guarantee that the
> interface you're coding to actually corresponds with reality, so you'll
> find yourself needing to run the entire stack for integration testing as
> well. If anyone has any good advice on making that actually happen I'd love
> to hear it, because we've yet to reach a point of being happy on that side.
>
> Jon
>
>
> On 23 June 2014 19:46, 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?
>>
>>  Thanks!
>> Jono.
>>
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140624/2799fecb/attachment-0003.html>