failures for WWW-Compete-0.01
Chris Mills
I uploaded my first module today (WWW-Compete-0.01) and I see that some
tests are failing. I believe that's because a Compete API key is required
before the tests can be successfully executed. There's a point in one of
the tests where the user is asked to input an API key, but I understand
that's not very helpful for automated testing.
I'd like to fix this. Can you provide any suggestions for handling this
scenario, or perhaps point me to a module that handles this in what you
would consider a well done way?
The failures I'm referring to are here:
http://www.cpantesters.org/author/C/CMILLS.html
Thanks for your help.
-- Chris
da...@cpan.org
ask Compete, Inc. for a test key that can be shared with the world under
public automated testing. If you get one, simply include it in your tests.
Failing that, come to terms with the fact that CPAN testers will be of limited
usefulness to you. Rework the interface to also accept a file to read the key
from. Document this. If the file does not exist, skip all tests that depend on
the key. (This similar to how I did it for Yahoo::Photos.) You will only get
test results which thoroughly exercise your module's functionality from the
users who set up the key file and made a report. In any case give hints in the
README file and TAP diagnostics that a better result can be achieved when a
tester takes the extra setup step.
Serguei Trouchelle
> I uploaded my first module today (WWW-Compete-0.01) and I see that some
> tests are failing. I believe that's because a Compete API key is required
> before the tests can be successfully executed. There's a point in one of
> the tests where the user is asked to input an API key, but I understand
> that's not very helpful for automated testing.
>
> I'd like to fix this. Can you provide any suggestions for handling this
> scenario, or perhaps point me to a module that handles this in what you
> would consider a well done way?
First of all, use prompt(), because direct reading from STDIN hangs smokers, and you may find your module in
disabled.yml, which is not very helpful for you either.
Then, skip all tests when no key is given.
--
Serguei Trouchelle
M W487
is that function supplied by some module like "use IO::prompt;" ?
Where can I find documentation for prompt() ?
Thanks.
David Golden
> I do not understand what you mean by "First of all, use prompt()" ---
> is that function supplied by some module like "use IO::prompt;" ?
>
> Where can I find documentation for prompt() ?
It's provided by both ExtUtils::MakeMaker and by Module::Build
use ExtUtils::MakeMaker;
my $answer = prompt("Pick a number",42); # 42 is the default
Module::Build does it the OO way, so it can be subclassed:
use Module::Build;
my $answer = Module::Build->prompt("Pick a number",42);
The important part is that prompt() won't prompt and will just use the
default if $ENV{PERL_MM_USE_DEFAULT} is true or if STDIN is empty.
Smoke testers generally set the PERL_MM_USE_DEFAULT to true.
-- David
da...@cpan.org
David Cantrell
> The important part is that prompt() won't prompt and will just use the
> default if $ENV{PERL_MM_USE_DEFAULT} is true or if STDIN is empty.
> Smoke testers generally set the PERL_MM_USE_DEFAULT to true.
The other important part is that prompt() knows about buffering, and so
if PERL_MM_USE_DEFAULT is *not* set, then there's a much better chance
that a real user who is, eg, piping CPAN.pm's output through another
programme (such as tee) will actually see what questions you're asking
him.
If you just print to STDOUT and read directly from STDIN, users will
sometimes not see the questions until after they've answered them. Or
more likely, they'll think your Makefile.PL crashed.
--
David Cantrell | Minister for Arbitrary Justice
You may now start misinterpreting what I just
wrote, and attacking that misinterpretation.