Skip Menu |

This queue is for tickets about the Rstat-Client CPAN distribution.

Report information
The Basics
Id: 35174
Status: open
Priority: 0/
Queue: Rstat-Client

People
Owner: isaacson [...] cpan.org
Requestors: CHORNY [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 2.2
Fixed in: (no value)



Subject: test.pl
Can you convert tests to Test::Simple/Test::More and move to t/ ? test.pl tests are not reported properly by CPANPLUS (there is no standard for test.pl) and require correct exit status. In addition, CPAN testers results may be incorrect because of this. -- Alexandr Ciornii, http://chorny.net
From: isaacson [...] cpan.org
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!