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

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.

Replies are listed 'Best First'.
Re^11: Cleaning up unused subroutines
by BrowserUk (Patriarch) on Oct 26, 2007 at 16:16 UTC
    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.
[reply]
[d/l]
[select]
      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]

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


        ___________
        Eric Hodges
[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]

In Section Seekers of Perl Wisdom