Using VCR to mock connection refused + timeout errors

[Eliot Sykes]

Hi all,

With webmock, I'm aware you can do something like this:

stub_request(:any, 'www.example.net').to_raise(StandardError.new("some
error"))
and
stub_request(:any, 'www.example.net').to_timeout

Does VCR support a way to mock raising timeout and connection refused
errors?

Kind regards,

Eliot

[Myron Marston]

Not directly, but there are some new (unreleased) features that would
allow you to do this:

VCR.configure do |c|
c.before_http_request do |request|
if request.uri == 'http://www.example.net/'
raise SomeError.new("boom")
end
end
end

I expect to release VCR 2.0.0.beta3 with this new feature some time
before the end of the month, or you can check out the master branch of
VCR on github--I try to keep things pretty stable.

HTH,
Myron

[Eliot Sykes]

Thanks Myron, I may check that out in the near future.

In case its of help to anyone else, for now I'm doing this with webmock to stub connection refused:

stub_request(:get, monitors_file.url).to_raise(Errno::ECONNREFUSED)

[Chris Adams]

@Elliot, are you using VCR and Webmock together in a single spec here?

I'm also trying to solve a similar issue - I'm trying to mock out some http interactions for a gem that wraps a remote API, like the one below: 

1 - authenticating against an API 

2 - getting a resource now I'm logged in

3 - simulating a timeout

4 - retrying the resource and making sure the response that comes back is what I was expecting

I get that I can use VCR to record the first two responses, ideally with separate requests, but I'm not sure how I might go about mocking out a single timeout, then making sure VCR records the correct interaction in the final request.

I'm somewhat new to VCR and webmock sure how best I could go about doing this. If anyone on the list could provide some pointers on doing this with VCR 1.11.3, I'd really appreciate it. 

Chris

[Myron Marston]

Good questions, Chris. I'll let Eliot respond about the specifics of
what he's doing, but here's my two cents as the author of VCR.

Timeout errors (and other connection errors) do not take place at the
level of the HTTP protocol. They take place at a lower-level--such as
at the socket.

VCR is concerned only with HTTP and knows nothing about errors such as
these. Different client libraries handle them very differently,
anyway, so it would be difficult to get VCR to handle all the cases
correctly. Plus, VCR is very much focused on the record/replay
paradigm. Timeouts and transient errors aren't easily recordable
since they aren't the "normal" response.

My suggestion is to figure out how your HTTP client library reacts to
a timeout (i.e. does it raise a particular error? does it return a
response object with a `#timed_out?` predicate method?) and use
whatever mock library you are using (rspec-mocks, mocha, rr or
flexmock) to simulate this condition.

Myron

[Chris Adams]

Wow, that was a fast response!

I think I've got enough to go on now.

Thanks Myron!

--
Chris Adams
mob: 07974 368 229
tel: 0207 558 8971
skype: chris.d.adams
twitter: mrchrisadams

[Hedge Hog]

On Mon, Nov 28, 2011 at 11:27 AM, Chris Adams <ma...@chrisadams.me.uk> wrote:
> Wow, that was a fast response!
>
> I think I've got enough to go on now.
>

Would be interested in what your approach is if you find one that works.
I have in mind to setup these sort of latency/time out/packet-loss
tests in their own cumcumber profile - simplyt because they require a
separate environemnt to be tested reliably.
What that environment is will vary. One such setup:
You can also use pfsense Firewall. Here are the general steps:

Install pfsense[0] in a VM[1] and [2]**.
Setup a Dummynet pipe/limiter[3] inside the firewall to limit
bandwidth and introduce packet delay/loss.
Change the router IP on your desktop computer to point to the one from
the new firewall.
Check (traceroute) all traffic uses the new firewall.
Check (mrt) the packet loss and delay.
Now that all traffic from your desktop goes through the limiter: Run
your scenarios concerning poor network connectivity.

** Vagrant is essential to making this painless and automated, but I'd
suggest waiting for >= 0.8.8 release, at the moment, 0.8.7, there are
significant issues with reliable ssh connections.
[0] http://www.pfsense.org/
[1] http://doc.pfsense.org/index.php/Installing_pfSense_in_vmware_under_windows
[2] http://vagrantup.com/
[3] http://doc.pfsense.org/index.php/Traffic_Shaping_Guide#Limiter

HTH?

--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://hedgehogshiatus.com

[Chris Adams]

Hi HedgeHog,

In the end, I took a different approach - so I didn't have to solve this exact problem in the end.

However, when browsing the list, Myron made a remark about VCR being designed to work on a granular basis, and I was lucky enough to have an API with optional 'authenticate' methods that I could separate into their own http request/response cycles first, before having to deal with the GET request that needs automatic retries.

By default, rspec's own matchers ended up being a little too general, so splitting into small responses meant I could fake the payload by pulling it out of a previous successful GET request, and loading it into the body of a webmock call.

I didn't actually need to do this in my case, but that's the approach I'd take in future.

Anyway, I've gisted up a link here to help explain - https://gist.github.com/1405862

The vagrant approach you outline sounds very thorough, but for this specific case, I think it goes beyond what I need - I might give it a spin in future though, once I get comfortable working with vagrant again!

Hope this helps!

C