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

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.

Replies are listed 'Best First'.
Re^13: Cleaning up unused subroutines
by eric256 (Parson) on Oct 26, 2007 at 18:20 UTC

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


    ___________
    Eric Hodges
[reply]
Re^13: Cleaning up unused subroutines
by BrowserUk (Patriarch) on Oct 26, 2007 at 18:54 UTC
    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]
        you'd simply go through each function, disabling its explicit tests then checking your coverage.

        FGS! If you comment out the tests of foo() in your test suite, then that is exactly the same as if you had no test suite.

        And, as I showed above, if you have a function call in your code that doesn't have an associated function definition, then Devel::Cover doesn't detect it.

        All you are doing it testing your tests, not your code.

        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