<div dir="ltr">I've had numerous issues trying to use VCR for exactly this purpose and would make the same recommendations as Mark.<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div class="gmail_extra">
<br clear="all"><div><div dir="ltr">Bestie.<br><div><br></div><div><a href="http://theaudaciouscodeexperiment.com" target="_blank">theaudaciouscodeexperiment.com</a><br><a href="http://github.com/bestie" target="_blank">github.com/bestie</a><br>
@thebestie</div></div></div>
<br><br><div class="gmail_quote">On 24 June 2014 13:20, Mark Burns <span dir="ltr"><<a href="mailto:markthedeveloper@gmail.com" target="_blank">markthedeveloper@gmail.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">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/" target="_blank">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"><div><div class="h5">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>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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><font color="#888888">
<div><br></div><div>-gabe</div></font></span></div>
<br></div></div><div class="">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">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></div></blockquote></div><br></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></div>