[LRUG] Testing SOAs

[Stephen Best]

I've had numerous issues trying to use VCR for exactly this purpose and
would make the same recommendations as Mark.

The main problem I encountered was request matching. Requests that you
consider to be the same may not be matched due to subtle differences in
headers or parameter ordering. The converse is also true where you want it
to differentiate and it can't.

Looking at the docs it seems some of these issues may have been resolved
but architecturally it's just a bad idea being coupled to HTTP and relying
on complex testing libraries.

Bestie.

theaudaciouscodeexperiment.com
github.com/bestie
@thebestie


On 24 June 2014 13:20, Mark Burns <markthedeveloper at gmail.com> wrote:

> Good point to emphasise that VCR is more useful for external vs internal
> services.
>
> Slightly related to the point of serialization/stubbing of APIs to ruby
> objects, I've not used it myself yet, but Google's
> Protocol Buffers
> <http://blog.codeclimate.com/blog/2014/06/05/choose-protocol-buffers/> whilst
> being a step away from the ubiquitous JSON format,
> looks useful. I'll certainly be considering it the next time I create any
> new services.
>
>
> On 24 June 2014 16:38, Gabe da Silveira <gabe at websaviour.com> wrote:
>
>> I totally agree with Mark and Jon on the subject.  VCR is a wonderful
>> tool, but it's sweet spot is for mocking out *external* services.  It's
>> perfect in that use case because you really want to have a concrete record
>> of every nuance of that external connection for when something breaks.
>>  However for internal services where you control both ends you have better
>> tools available (logging, exceptions, introspection, etc), and VCR is too
>> blunt a tool.
>>
>> The approach that I've taken (which I talked about last month:
>> https://skillsmatter.com/skillscasts/5283-deprecating-activeresource-alternative-approaches-for-internal-rails-services),
>> is to use a private gem that is shared between the consumer and provider.
>>  The core idea in the private gem is guaranteeing serialization of the
>> service objects, so we aren't just relying on JSON with vague semantics,
>> but we have real models which are shared and identical on both ends.  This
>> partially addresses Jon's point about ensuring the interface matches
>> up—it's not perfect as the gem doesn't know the context of an API response,
>> but at least it does ensure that the serialization and interpretation of an
>> object is identical on both sides, and it does so without any brittle
>> system level tests that could be defeating the purpose of an SOA in the
>> first place.
>>
>> With regards to stubbing, since we are using ruby on both ends, we
>> include some testing tools in the gem.  One is a very lightweight factory
>> system.  Each model has a corresponding factory which represents a standard
>> object.  Because these are isolated POROs, it's really just a hash of
>> attributes, nothing fancy like FactoryGirl needed.  Then, the key bit, is a
>> module called ClientStubs which uses Mocha under the hood to provide higher
>> level stubs/expectations that leverage our conventions about how different
>> API calls are structured.  This lets us stub very tersely just above the
>> HTTP level, but with sensible defaults and a reasonable amount of
>> flexibility.
>>
>> -gabe
>>
>> _______________________________________________
>> 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/02d68358/attachment-0003.html>