David Cantrell wrote:
> Yitzchak Scott-Thoennes wrote:
>> David Cantrell wrote:
>>> Any test suite that blithely ignores warnings is BROKEN.
>>> The second type of warning is the one that tells you when you the
>>> author
>>> have fucked up, like, when you say "my $variable" twice, or saying
>>> "$variable = 'one thing'" and "$varable = 'something else'". I deal
>>> with those by having $SIG{__WARN__} turn them into die()s in the tests.
>>> If you don't deal with them, you're saying that you don't care about
>>> tripping yourself up in the future.
>> I have to disagree here. You are saying that it is the test's
>> responsibility to fail if it issues any warnings. I believe
>> an author may choose to scan the test output and rely on seeing
>> messages to go to stderr.
>
> Please, tell me how I can scan the test output on - say - Windows. Bear
> in mind that I do not own a Windows licence, nor do I have any hardware
> that will run Windows without lots of annoying faffing around.
You don't. Or you take the extra step to have your test detect and fail
on warnings. But there are downsides, see below.
> When a user installs my module on Windows, he will probably type
> something like:
>
> C:\> perl -MCPAN -e 'install Daves::Module'
>
> which will handle any dependencies for him. If my module - or one of
> the dependencies - spits out a warning, the user is likely to miss it
> when it scrolls past too fast to read. Even worse, he might see it, and
> ignore it because of the bit at the bottom that says "all tests passed".
> THAT is why I believe warnings in tests should be fatal by default.
I support your right to make your warnings fatal, but I'd not like
to see that become the default. New versions of perl can enable new
warnings. If you want to ensure that you are an early tester of new
perl versions against your modules, you can get by with having to
release new module versions as needed. But for the greater number
of perfectly decent modules out there that just sit unchanged for
years, it's too harsh to have them start failing tests out of the
blue.
> It means I am more likely to get useful bug reports. It also means I'll
> get "pro-active" bug reports from the CPAN testers.
>
> > Obviously it's better to do as you
>> propose, but that takes extra work in every test to implement.
>
> $SIG{__WARN__} = sub { die(@_) };
>
> so much extra work! Or if you're less of a depdencies-fascist than I
> am, use Test::NoWarnings for even less typing.
>
>> Authors should not be counted on to do so
>
> Authors are giving their work away for free. They shouldn't be counted
> on to do *anything*.
>
> > and when they don't
>> go that extra mile, their warnings should not just get lost.
>
> Of course. It would be nice if they weren't *ignored* though.
That's exactly what I'm saying; that changing from displaying STDERR
to silently suppressing it is a BAD THING(tm). I thought you were
arguing the opposite; that it's ok to do so because tests that don't
catch warnings are already broken.
> Hrrm, I'm going to go away now and think about how I can inject that
> __WARN__ handler into everyone elses tests when I run them :-)
sitecustomize.pl and $0 =~ /(?:\.t|test\.pl)\z/ ?
