[LRUG] Testing SOAs

[Jonathan Fantham]

Absolutely awesome responses here! Thanks for that.

I especially like that I started off favouring VCR and over the course of the last few days that's slowly changed as I've come to realise that I just haven't used VCR enough to hit the problems others have already hit. That's exactly what I hoped for! Experienced advice from the trenches.

So thanks, I haven't managed to read all the links yet but I'll be going through them all, and hopefully after all the reading I'll have a clear idea of how to avoid future pain.

Thanks again,
Jono.

On 24 Jun 2014, at 16:40, Stephen Best <bestie at gmail.com> wrote:

> 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 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
> 
> 
> _______________________________________________
> 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/bdc9bb88/attachment.html>