Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Removed -w flag from #! lines.

  • Loading branch information...
commit 22db0a765bd3e80642d869e8989329b4b2889d4c 1 parent d24d1b6
chromatic authored September 19, 2011

Showing 1 changed file with 7 additions and 7 deletions. Show diff stats Hide diff stats

  1. 14  lib/Test/Tutorial.pod
14  lib/Test/Tutorial.pod
Source Rendered
@@ -30,7 +30,7 @@ you.  And here are the tricks...
30 30
 
31 31
 Here's the most basic test program.
32 32
 
33  
-    #!/usr/bin/perl -w
  33
+    #!/usr/bin/perl
34 34
 
35 35
     print "1..1\n";
36 36
 
@@ -50,7 +50,7 @@ results to determine if you succeeded or failed (more on that later).
50 50
 Writing all these print statements rapidly gets tedious.  Fortunately,
51 51
 there's B<Test::Simple>.  It has one function, C<ok()>.
52 52
 
53  
-    #!/usr/bin/perl -w
  53
+    #!/usr/bin/perl
54 54
 
55 55
     use Test::Simple tests => 1;
56 56
 
@@ -61,7 +61,7 @@ of Perl testing, and we'll be using it instead of roll-your-own from
61 61
 here on.  If C<ok()> gets a true value, the test passes.  False, it
62 62
 fails.
63 63
 
64  
-    #!/usr/bin/perl -w
  64
+    #!/usr/bin/perl
65 65
 
66 66
     use Test::Simple tests => 2;
67 67
     ok( 1 + 1 == 2 );
@@ -95,7 +95,7 @@ whole module.  Best place to start is at the beginning.  Date::ICal is
95 95
 an object-oriented module, and that means you start by making an
96 96
 object.  So we test C<new()>.
97 97
 
98  
-    #!/usr/bin/perl -w
  98
+    #!/usr/bin/perl
99 99
 
100 100
     use Test::Simple tests => 2;
101 101
 
@@ -140,7 +140,7 @@ Simplest way to build up a decent testing suite is to just test what
140 140
 the manual says it does. [3] Let's pull something out of the 
141 141
 L<Date::ICal/SYNOPSIS> and test that all its bits work.
142 142
 
143  
-    #!/usr/bin/perl -w
  143
+    #!/usr/bin/perl
144 144
 
145 145
     use Test::Simple tests => 8;
146 146
 
@@ -191,7 +191,7 @@ can't tell you what went wrong.  Instead, we'll use the C<is()>
191 191
 function, which lets us declare that something is supposed to be the
192 192
 same as something else:
193 193
 
194  
-    #!/usr/bin/perl -w
  194
+    #!/usr/bin/perl
195 195
 
196 196
     use Test::More tests => 8;
197 197
 
@@ -355,7 +355,7 @@ for you or for the next person who runs your test.
355 355
 Poking around in the existing Date::ICal tests, I found this in
356 356
 F<t/01sanity.t> [7]
357 357
 
358  
-    #!/usr/bin/perl -w
  358
+    #!/usr/bin/perl
359 359
 
360 360
     use Test::More tests => 7;
361 361
     use Date::ICal;

3 notes on commit 22db0a7

Michael G. Schwern

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

chromatic
Owner

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?

Michael G. Schwern

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.
Something went wrong with that request. Please try again.