without having to write a test suite that exercises every code branch, which isn't always (or even usually) possible.

Your code should be designed so that testing every branch is possible. If you're writing code that's hard to test, you can't test it, and therefore it's quite possible that some bug will show up in the future. Bad code, Bad code, what you gonna do?

Read Test::Tutorial. Learn how to write tests, and you'll gradually start writing code that can always be tested.

What tutorial you are talking about? I've not found anything on CPAN except "Here should be extensive documentation on what unit testing is, why it is useful, and how to do it with the Test::Unit collection of modules. Sorry for not implementing this yet." :(
http://search.cpan.org/~aspiers/Test-Unit-0.24/lib/Test/Unit/Tutorial.pm

Please post the full URL.

--dda

It's part of the Test::Simple package, and can be found here.

    if ($mday == 1 && $month == 1) {
        handelNewYear;   # Typo in function name.
    }
[download]

Leaving parens off isn't always possible without writing uncommon idiom, but in many cases you can leave the parens off, and it'll capture many mistyped sub names.

Abigail

Very cool, thanks Abigail-II.

Exactly the kind of wisdom I was hoping for :)


Mike

Just as a new Perl programmer might get tired of hearing "use strict" or "use CGI", you're going to get tired of hearing "write tests" if you have a problem which testing tends to solve. Use Devel::Cover to develop a code coverage profile and you have a good start on writing your tests. I'll even help:

use strict;
use warnings;
use Test::More 'no_plan';
my $module = 'Foo.pm';

use_ok($module) or die;

can_ok($module, 'handleNewYear');
[download]

Then, just fill in "can_ok" stubs for your functions. As you uncover bugs, write a test that exploits them. It's not quite the same as test driven development, but I'm scratching my head trying to think of ways to get people to test who otherwise wouldn't :)

But it would be nice if there was a way to catch such cases...

Well, you've answered your own question when you said:

"there could be autoloads providing the subroutine, or it could have been dynamically generated at runtime in an eval, or something. "

The flexibility of Perl comes with a price. This is one of them.

However, I would strongly disagree when you said:

without having to write a test suite that exercises every code branch, which isn't always (or even usually) possible.

If you can't test your code then something is wrong with it. Fix the design so you can test it. If you have problems doing this, then post a SOPW - I'm sure somebody could help ;-)

Seriously, 100% test coverage is an attainable goal with surprisingly little effort.

You can say that it has been the price, but I see a good niche for adding the ability to turn on stronger checking in this area.

Even with subs dynamically generated at runtime or handled via AUTOLOAD, offhand I can think of no case where there couldn't be at least a declaration at hand at compile time. It is Unfortunate that sub declarations aren't common enough in CPAN modules to allow this to be a default check.

Of course it is technically possible to see if an appropriate entry exists in the symbol table at runtime. However, forcing everybody to add declarations for any runtime-generated subroutines strikes me as both un-perlish and extremely unlikely to happen.

So as merly and everyone else have pointed out, at the end of the day, you have to have test cases cover all braches. Brach could mean different things for different testing phases. For the unit testing that you should do, branch means each logic branch of all your scripts.

On the other hand, I agree that it would be nice, if Perl can help you to avoid some of those pitfalls.

Now, how many times have you run into nasty problems by misspelling your hash keys? (In this case -w and strict does not help) But in this in this case Perl provides a great tool: Hash::Util:

foo.pm:
package foo;
use Hash::Util;
use strict;
use warnings;

sub new {
    my $self = {};
    $self->{XBCDE} = 1;
    $self->{AXCDE} = 2;
    $self->{ABXDE} = 3;
    $self->{ABCXE} = 4;
    $self->{ABCDX} = 5;
    bless($self);
    Hash::Util::lock_keys(%{$self});
    return $self;
}

sub bar_1 {
    my $self = shift;
    $self->{AXCDE} = 10;
}

sub bar_2 {
    my $self = shift;
    print $self->{AXCDE};
}

sub bar_3 {
    my $self = shift;
    $self->{XXXXX} = 10;
}

sub bar_4 {
    my $self = shift;
    print $self->{XXXXX};
}

1;

foo.pl:
use foo;
use strict;
use warnings;

my $foo = new foo;
$foo->bar_1; #okay as the key exists
$foo->bar_2; #okay as the key exists
$foo->bar_3; #no good, comment out this, and try for the second time
$foo->bar_4; #no good, comment out this, and try for the third time
[download]

my $handleNewYear = sub {
    # do something really useful
};

# ... lotsa logic...
if (1==$mday && 1==$month) {
    $handelNewYear->();
}
[download]

You may note that I also reversed the order of your == comparisons. The reason for doing that is so that if you type = instead of == some day, Perl will complain because you can't assign to a constant. This is a useful habit in many C-like languages.

I read this thread earlier today and I have to admit that I skimmed over the bit about == comparisons and then just now I was reading about the back door attempt on the Linux kernel and way down there in the comments (sorry I can't see a way to link directly to it) are two comments by "legobuff" and "Mr_Z" on the exact same topic. A real world example how a simple change in coding practice can potentially make a profound difference (presuming of course some-one writes the auditing tools). ++tilly its a good meme to spread.

--
Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

This intrigues me.
but
Why do you say "Probably don't want to..."?
because
"it's too much work"?
or because
"it's dangerous/bad/ugly"?

Don't know, but one downside (upside?) is that your functions are no longer accessible from outside the package. That can easily be fixed by doing one of the following for exportable functions:

*handleNewYear = my $handleNewYear = sub {
    # do something really useful
};
[download]

sub handleNewYear {
    # do something really useful
}

my $handleNewYear = \&handleNewYear;
[download]

Because it is ugly. And will be sure to generate negative comments from any maintainance programmer. And cannot be mixed with OO techniques.

Other than that, it is a veru good idea. But its goodness is simply not worth the arguments that you're bound to generate.

sub foo{
  my $thing = shift;
  print $thing->to_xml;
}
[download]

Snarf in your script from another script. The second
script will declare any sub it comes across:

if( $line =~ m!sub\s+(\S+){ eval "sub $1 {}" }
[download]

I hope my advice helps.
-Jacob
Eat Perl, live well.
My site

I've published elsewhere a little script which parses the output of B::Xref to catch unused subs. if you just change the last four lines to:

foreach my $sub (keys %subused) {
    next if exists $subdef{ $sub };
    print "UNDEFINED SUB: $subused{ $sub } $sub\n";
}
[download]

Thanks!

I think both the unused and undeclared options look pretty useful.

Your post is a reply to Warnings for unused subs, an interesting thred I'd missed.


Mike

PS: I liked that side trip to Re: Re: ESMTP, linefeed and <CRLF> before you fixed your link; it made me wonder if I'd accidentally gotten decaf this morning :)

Of course, Perl is a bit tougher to parse than C, so my perl version of the tool is "less deterministic"... Still, I wonder if something like this might help in your case, at least to give a decent starting point for the diagnostics that you really want. Basically, it's a matter of comparing the sub calls against the sub declarations to see if there are any "outliers".