in reply to Re^10: Cleaning up unused subroutines
in thread Cleaning up unused subroutines

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."

Replies are listed 'Best First'.
Re^12: Cleaning up unused subroutines
by Somni (Friar) on Oct 26, 2007 at 17:57 UTC
    f 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().

    Granted, but you could remove the tests that explicitly test foo(), and see where you stand. If nothing in your code library calls it that would at least tell you that your own code doesn't use the function.

    And this is far from the only situation in which test suites give you a falsely heightened sense of well-being.

    I'm not really clear on what you're saying here. So, because test suites give some programmers a falsely heightened sense of well-being, no one should implement test suites?

    A test suite is not a silver bullet, it's simply a tool to help you solve problems with your code.

[reply]
      Granted, but you could remove the tests that explicitly test foo(), and see where you stand.

      But then you'd have to know that foo() wasn't used--and that is exactly what the OP is trying to discover.

      This is not about the utility of tests, or test suites. It's about about solving the OPs problem, and testing your test suite will not do that.

      It's also (as an aside to the OPs question), about the limitations of unit test suites and realising that they are only a part of the picture. They must be combined with proper system tests, that is running the real code with realistic data under realistic operating conditions, because coverage tools show you what you've remembered to test, not what you didn't.

      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.
[reply]
        You wouldn't have to know that specifically foo() wasn't used, you'd simply go through each function, disabling its explicit tests then checking your coverage.

        The test suite is being used here as an automated means of testing with as many inputs as possible. Something not easily done with your original proposed solution. Your solution misses code; utilizing the test suite has a chance of missing less.

[reply]

      I think the point was that tests wont help find unused sub routines. Not that tests shouldn't be written.


      ___________
      Eric Hodges
[reply]

In Section Seekers of Perl Wisdom