Best practice for unit tests that rely on internet access?

[Toby Wintermute]

On 1 May 2011 08:34, David Precious <davidp at preshweb.co.uk> wrote:
> On Friday 29 April 2011 08:33:47 Leon Brocard wrote:
>> If the module is all about testing a live service then by all means test
>> it. Unless it takes too long, or costs money, or might change in the
>> future when you don't have time to update the module...
>
> Arguably, if whatever service the module talks to changes in the future in a
> way which stops the module working, failing test reports helps to highlight
> that; even if the developer doesn't have time to fix it, it highlights to
> potential users that the module "doesn't work" any more.
>
> That, to me, is a good reason to offer the ability to test against the real
> service.

I agree with this; if the web service changes enough to break
compatibility with my module, then a slew of FAIL reports will make
this clear to myself, and users.

> On the other hand, you could end up with incorrect failure reports when the
> service is temporarily unavailable, or cannot be reached due to a restrictive
> firewall, for instance.  Having to "force install" because the tests fail
> because the firewall hasn't been updated to allow connections yet isn't too
> pretty.

Also true. Hmm :/

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world