This is also related to the following mail thread:
From: Ron Isaacson
Subject: Re: Rstat-Client-2.2 test failures
Date: Thu, 17 Apr 2008 20:56:53 -0400
To: David Cantrell <david@cantrell.org.uk>
Cc: cpan-testers-discuss@perl.org
Hi David --
David Cantrell wrote:
Show quoted text>
> I'm one of the CPAN-testers, who try to test everything that gets
> uploaded to the CPAN on as many platforms as possible.
>
> On Solaris, Rstat-Client-2.2 failed one of its tests:
>
> > Running make test
> > PERL_DL_NONLAZY=1
> > /usr/local/home/david/cpantesting/perl-5.10.0/bin/perl
> > "-Iblib/lib" "-Iblib/arch" test.pl
> > 1..4
> > ok 1
> > ok 2
> > not ok 3
> > ok 4
>
> It then exited with a 0 status, which I believe is taken by CPAN.pm
> and friends to mean that the tests *passed*. As a result, if I were a
> real user and not just testing it, I would now have a version of your
> module installed that fails its tests, maybe without noticing that the
> test had failed. This could lead to some very hard to diagnose bugs.
Thanks for the feedback! In order to complete its tests, Rstat::Client
needs to be able to contact an rstatd, and the test suite assumes
there's one running on localhost, for lack of anywhere better to look.
Because it's not all that uncommon to NOT find an rstatd on localhost,
this error is not fatal -- the module is still likely to work. This
could definitely be better documented though.
Show quoted text> I would also point out that on several other of my testing machines,
> test.pl appeared to hang after the first two tests and I interrupted
it
Show quoted text> with control C after a couple of minutes. If the tests are expected
to
Show quoted text> take a long time, it might be worthwhile warning the user.
Unfortunately, I just realized the test suite is inconsistent.
Although it's perfectly happy not to find an rstatd running locally,
it does NOT use the "timeout" option to fetch(). According to the
documentation, when that option is not used, fetch() "will block until
a response is returned." If no response ever comes back, it will block
forever.
The timeout option is meant to avoid that, and it should be used by
the test suite.
I'll make a note to fix both of these in the next release. Thanks
again, and let me know if you have any other suggestions!