<div dir="ltr">Hi Sam (and so on)<div><br></div><div>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.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr">I think it's worth identifying the division(and function) of smoke tests as opposed to acceptance tests. One to ruminate on.</div><div dir="ltr"><br></div><div>Tim</div><div dir="ltr"><br><span style="font-size:x-small">Tim Diggins</span><br></div><div dir="ltr"><span style="font-size:x-small">Director, Red56 Ltd </span><span style="font-size:x-small"><a href="http://www.red56.uk" target="_blank"><font color="#ff0000">http://www.red56.uk</font></a></span></div><div dir="ltr"><font size="1">Red56 helps businesses become more efficient by developing, maintaining, and integrating workflow software.<br></font></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 18 Sep 2018 at 10:17, Samuel Joseph <<a href="mailto:tansaku@gmail.com">tansaku@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hi Mark,</p>
<p>That's a great blog post - thanks for sharing :-)</p>
<p>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).</p>
<p>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 ...</p>
<p>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 ...</p>
<p>Many thanks again</p>
<p>Best, Sam<br>
</p>
<br>
<div class="m_6774130200365851684moz-cite-prefix">On 11/09/2018 11:05, Mark Burns wrote:<br>
</div>
<blockquote type="cite">
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).<br>
<br>
It might be easier for you to wrap your services in a gem or
library and inside that library thoroughly test the HTTP
interactions.<br>
<br>
Then outside of the library avoid the leaky http abstraction.<br>
<br>
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.<br>
<br>
<a href="http://blog.polyglotsoftware.co.uk/2014/02/07/a-pattern-for-stubbing-out-apis-with-rspec.html" target="_blank">http://blog.polyglotsoftware.co.uk/2014/02/07/a-pattern-for-stubbing-out-apis-with-rspec.html</a><br>
<br>
(Apologies in advance if you are not making this same mistake)<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, 11 Sep 2018 at 10:44, Samuel Joseph <<a href="mailto:tansaku@gmail.com" target="_blank">tansaku@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lrugers,<br>
<br>
Any thoughts on how to manage VCR caches effectively in a team
context?<br>
<br>
<a href="https://github.com/vcr/vcr" rel="noreferrer" target="_blank">https://github.com/vcr/vcr</a><br>
<br>
We have a few open source projects using VCR, and we have the
recordings <br>
of the network communication checked into git so that all
developers can <br>
run tests in a consistent network environment.<br>
<br>
I have two concerns<br>
<br>
1) new developers onboarding often get snarled up in the
caching and the <br>
files generated<br>
2) the cached recordings are gradually getting further and
further out <br>
of date - could we automate their refreshing?<br>
<br>
I have reached out to the VCR community in the past, but
haven't had <br>
much feedback:<br>
<br>
* <a href="https://github.com/vcr/vcr/issues/672" rel="noreferrer" target="_blank">https://github.com/vcr/vcr/issues/672</a><br>
* <a href="https://github.com/vcr/vcr/issues/719" rel="noreferrer" target="_blank">https://github.com/vcr/vcr/issues/719</a><br>
* <a href="https://groups.google.com/forum/#%21topic/vcr-ruby/8DoA7MUq-38" rel="noreferrer" target="_blank">https://groups.google.com/forum/#!topic/vcr-ruby/8DoA7MUq-38</a><br>
<br>
I wondered if anyone else was using VCR and how they were
making it work <br>
well for them with their team. Perhaps people are not using
it and <br>
doing something else?<br>
<br>
Many thanks in advance<br>
<br>
Best, Sam<br>
<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote>
</div>
<br>
<fieldset class="m_6774130200365851684mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
Chat mailing list
<a class="m_6774130200365851684moz-txt-link-abbreviated" href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a>
Archives: <a class="m_6774130200365851684moz-txt-link-freetext" href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a>
Manage your subscription: <a class="m_6774130200365851684moz-txt-link-freetext" href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a>
List info: <a class="m_6774130200365851684moz-txt-link-freetext" href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div>