[LRUG] Testing SOAs

[Mark Burns]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140624/80056dd3/attachment-0003.html>