<div dir="ltr">Good point to emphasise that VCR is more useful for external vs internal services.<div><br></div><div>Slightly related to the point of serialization/stubbing of APIs to ruby objects, I've not used it myself yet, but Google's</div>
<div><a href="http://blog.codeclimate.com/blog/2014/06/05/choose-protocol-buffers/">Protocol Buffers</a> whilst being a step away from the ubiquitous JSON format,<br></div><div>looks useful. I'll certainly be considering it the next time I create any new services.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 June 2014 16:38, Gabe da Silveira <span dir="ltr"><<a href="mailto:gabe@websaviour.com" target="_blank">gabe@websaviour.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>

<br></div><div>The approach that I've taken (which I talked about last month: <a href="https://skillsmatter.com/skillscasts/5283-deprecating-activeresource-alternative-approaches-for-internal-rails-services" target="_blank">https://skillsmatter.com/skillscasts/5283-deprecating-activeresource-alternative-approaches-for-internal-rails-services</a>), 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.</div>

<div><br></div><div>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.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-gabe</div></font></span></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>