[LRUG] VCR caches

Tue Sep 18 02:33:25 PDT 2018

Hi Sam (and so on)

very interesting thread and post. I hear what you're  half in each camp. I
think a few "smoke tests" with as realistic end points as possible are
really great -- but for me, these need to run primarily on CI rather than
on developer machines (so VCR never seems like an option to me, but maybe I
just don't understand it well enough) -- and I've tried to go with fully
real services (e.g. a real google sheet, a real (but sandboxed) payment
processor) etc. Then if I've got a smoke test ~ per service, then hopefully
it is just flakey enough to fail when something substantial changes with
that service (or our usage of it), and hopefully not so flakey that we just
say -- oh that's just that flakey smoke test, let's ignore it (though
"rerun" on CI usually gets around that.

I think it's worth identifying the division(and function) of smoke tests as
opposed to  acceptance tests. One to ruminate on.

Tim

Tim Diggins
Director, Red56 Ltd http://www.red56.uk
Red56 helps businesses become more efficient by developing, maintaining,
and integrating workflow software.

On Tue, 18 Sep 2018 at 10:17, Samuel Joseph <tansaku at gmail.com> wrote:

> Hi Mark,
>
> That's a great blog post - thanks for sharing :-)
>
> The rule of thumb that we've been following is to make our acceptance
> tests (using Cucumber/Capybara/RSpec) as "realistic" as possible, so they
> use VCR as much as possible, and webmock in places where we need extra
> confirmation about network connections (just reviewing I think we're mainly
> recording interactions with 3rd party services such as stripe,
> pivotaltracker, codeclimate and github).
>
> Our unit tests are all well stubbed, and then the integration tests have a
> mix of gem stubbing and webmock.  You might well be right, and perhaps we
> need to give up on purist "realism" in our acceptance tests and use more
> gem/library stubbing ...
>
> What's unclear is how much the more "realistic" acceptance tests have ever
> bought us (nothing? a little? a lot?), compared to the trouble it creates
> for new developers trying to manage the VCR caches ...
>
> Many thanks again
>
> Best, Sam
>
> On 11/09/2018 11:05, Mark Burns wrote:
>
> Generally I think people tend to test HTTP services at the wrong
> abstraction. So it might be why it’s a pain point for you. Your non http
> related test code ends up having to know about http (via VCR or web mock or
> whatever).
>
> It might be easier for you to wrap your services in a gem or library and
> inside that library thoroughly test the HTTP interactions.
>
> Then outside of the library avoid the leaky http abstraction.
>
> I’ve seen and done it myself so I wrote a post about it a few years ago.
> It’s probably a bit dated now.
>
>
> http://blog.polyglotsoftware.co.uk/2014/02/07/a-pattern-for-stubbing-out-apis-with-rspec.html
>
> (Apologies in advance if you are not making this same mistake)
> On Tue, 11 Sep 2018 at 10:44, Samuel Joseph <tansaku at gmail.com> wrote:
>
>> Hi Lrugers,
>>
>> Any thoughts on how to manage VCR caches effectively in a team context?
>>
>> https://github.com/vcr/vcr
>>
>> We have a few open source projects using VCR, and we have the recordings
>> of the network communication checked into git so that all developers can
>> run tests in a consistent network environment.
>>
>> I have two concerns
>>
>> 1) new developers onboarding often get snarled up in the caching and the
>> files generated
>> 2) the cached recordings are gradually getting further and further out
>> of date - could we automate their refreshing?
>>
>> I have reached out to the VCR community in the past, but haven't had
>> much feedback:
>>
>> * https://github.com/vcr/vcr/issues/672
>> * https://github.com/vcr/vcr/issues/719
>> * https://groups.google.com/forum/#!topic/vcr-ruby/8DoA7MUq-38
>>
>> I wondered if anyone else was using VCR and how they were making it work
>> well for them with their team.  Perhaps people are not using it and
>> doing something else?
>>
>> Many thanks in advance
>>
>> Best, Sam
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
>
> _______________________________________________
> Chat mailing listChat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: 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/20180918/98f1de6c/attachment-0004.html>