Browse files

Removed -w flag from #! lines.

  • Loading branch information...
1 parent d24d1b6 commit 22db0a765bd3e80642d869e8989329b4b2889d4c @chromatic committed Sep 20, 2011
Showing with 7 additions and 7 deletions.
  1. +7 −7 lib/Test/Tutorial.pod
@@ -30,7 +30,7 @@ you. And here are the tricks...
Here's the most basic test program.
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
print "1..1\n";
@@ -50,7 +50,7 @@ results to determine if you succeeded or failed (more on that later).
Writing all these print statements rapidly gets tedious. Fortunately,
there's B<Test::Simple>. It has one function, C<ok()>.
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use Test::Simple tests => 1;
@@ -61,7 +61,7 @@ of Perl testing, and we'll be using it instead of roll-your-own from
here on. If C<ok()> gets a true value, the test passes. False, it
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use Test::Simple tests => 2;
ok( 1 + 1 == 2 );
@@ -95,7 +95,7 @@ whole module. Best place to start is at the beginning. Date::ICal is
an object-oriented module, and that means you start by making an
object. So we test C<new()>.
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use Test::Simple tests => 2;
@@ -140,7 +140,7 @@ Simplest way to build up a decent testing suite is to just test what
the manual says it does. [3] Let's pull something out of the
L<Date::ICal/SYNOPSIS> and test that all its bits work.
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use Test::Simple tests => 8;
@@ -191,7 +191,7 @@ can't tell you what went wrong. Instead, we'll use the C<is()>
function, which lets us declare that something is supposed to be the
same as something else:
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use Test::More tests => 8;
@@ -355,7 +355,7 @@ for you or for the next person who runs your test.
Poking around in the existing Date::ICal tests, I found this in
F<t/01sanity.t> [7]
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use Test::More tests => 7;
use Date::ICal;

3 comments on commit 22db0a7


Why remove -w? It turns on global warnings which is a Good Thing while testing.


I see little value in getting warnings from unrelated dependencies. Am I supposed to monkeypatch SQL::Translator::Schema not to give warnings when run from 'make test', for example? What happens when you combine this with Test::NoWarnings?

schwern commented on 22db0a7 Oct 4, 2011
  1. Test::Harness is going to turn them on anyway, so this avoids having differing behavior between "make test" and "prove" and running the test by hand. Tests should run consistently.

  2. Yes, you are supposed to deal with warnings in dependencies. They're often related to what you did. For example, if I drop an undefined variable into a function, it would be nice if the function explicitly checked for that, but if it doesn't I want to see it bang into things all the way down. It tells me I made a mistake, which is what warnings are supposed to do.

  3. Yes, you are supposed to deal with warnings in dependencies. They may indicate that the dependency is broken or unreliable.

  4. Yes, you are supposed to deal with warnings from dependencies because if you don't your users certainly will. You are to be aware of them, work around them as best you can, and submit a bug report. For example, perl5i uses Object::ID (let's ignore that I maintain both). Object::ID warns when used on 5.10.0 because of a use v5.10 which 5.10.0 got snippy about. Without -w I would not have seen it but my users sure would have.

If the warning is truly something out of your control and unrelated to what you're doing, then you may turn warnings off locally either with a local $^W or a local $SIG{__WARN__} to suppress that specific warning. But your users will still see it, so it's just ignoring the problem.

If you don't deal with -w then you are A) rejecting the utility of warnings and B) somebody else will. There will always be false positives. The solution is to find and silence them, and make the whole ecosystem you rely on better, not to put on blinders and claim it's not your business.

Please sign in to comment.