So, what you are saying is that the advice to "build a comprehensive test suite" and then use a manual, step-by-step "rename a sub at random and run the test suite to see what happens" advice will, after all the laborious and manually intensive effort involved, miss the very same example that your pointed out that my fast and mostly automated method would miss:

C:\test>type junk8.pl
#! perl -slw
use strict;

foo() if @ARGV;

C:\test>perl -MDevel::Cover junk8.pl
Devel::Cover 0.61: Collecting coverage data for branch, condition, pod
+, statement, subroutine and time.
Selecting packages matching:
Ignoring packages matching:
    /Devel/Cover[./]
Ignoring packages in:
    .
    c:/Perl/lib
    c:/Perl/site/lib

Devel::Cover: Can't find file "blib\lib\Storable.pm" (blib\lib\Storabl
+e.pm (autosplit into blib\lib\auto\Storable\retrieve.al)): ignored.
Devel::Cover: Writing coverage database to C:/test/cover_db/runs/11934
+13458.532.60512

---------------------------- ------ ------ ------ ------ ------ ------
+ ------
File                           stmt   bran   cond    sub    pod   time
+  total
---------------------------- ------ ------ ------ ------ ------ ------
+ ------
junk8.pl                      100.0   50.0    n/a  100.0    n/a  100.0
+   85.7
Total                         100.0   50.0    n/a  100.0    n/a  100.0
+   85.7
---------------------------- ------ ------ ------ ------ ------ ------
+ ------
[download]

There is no subroutine foo() defined in my example, so Devel::Cover has no way of knowing to check to see if it's covered. My example was not intended to show the effects of an undefined subroutine that's never called. It was to show how simply running one bit of code to check for subroutine calls is not going to catch everything; you have to try and touch every bit of code in order to successfully do that.

I get the feeling you're leading me around by the nose in order to make some point. If you have a point to make, please make it so we can discuss it.

If you have a point to make, please make it so we can discuss it.

Okay.

If the code has a function foo(), and you have dilligently added one or more tests in your comprehensive test suite that exercise foo(), then instrumenting your test suite is never going to tell you that your code no longer calls foo().

And this is far from the only situation in which test suites give you a falsely heightened sense of well-being. Test suites only test those things you thought of to test. If test suites were "comprehensive", then those modules out there written using the TDD methology would never receive bug reports--but they do.

It's a little like testing the temperature of the water by sticking a thermometer in it for a few seconds and then pressing the end against your tongue to see if it is too hot.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."