Best practice for unit tests that rely on internet access?
makk384 at gmail.com
Thu May 5 19:13:18 BST 2011
On 29 April 2011 02:15, Toby Wintermute <tjc at wintrmute.net> wrote:
> What is the best practice for writing unit tests that rely on internet
> ie. You have a CPAN module which is all about talking to a web
> service.. So you have unit tests that do just that.
> What if the system testing it doesn't allow HTTP connections out? The
> tests will fail..
> Should one
> a) Prompt the user for whether to skip the tests? (I hate this
> option.. I dislike interactivity in installers)
> b) Only run the tests if specifically set by AUTHOR_TEST or something,
> otherwise mock the server? (I dislike this.. means few good tests run
> for users)
> c) Try to test if there's a working connection, and silently skip the
> tests if not? (Risks skipping tests if the connect fails for other
> reasons than no outbound HTTP allowed)
> d) ???
If you're using LWP, take a look at LWP::UserAgent::Mockable . It was
exactly this kind of situation that it was written for.
The main behaviour depends on the mode you're in (controlled by environment
variable when running the script):
- record - will make all of the LWP calls, and store the request &
response for each to local file
- playback - will intercept all LWP calls, returning the ones from the
- passthrough - go direct to the the remote end, without any wrapping
For the simple case, there's only a single line change required to your test
It's not an ideal solution, in that you aren't able to confirm that the
responses from the remote system haven't changed, but it's better than
having to rely on integration tests with remote systems that are often down
Lemme know if you have any issues with interface, and I'll see what I can do
about an update. It's been a while since I've updated that, and there are a
couple of things I want to modify for it myself.
More information about the london.pm