Re: Testaholics Anonymous (or how I learned to stop worrying and love Test::More)

[xdg]

After reading an article on it in TPJ and trying it out, I strongly recommend checking out Devel::Cover. It automates the process of seeing how much of your code is actually tested by your test suite and produces a fantastic HTML drill-down report. It will track the execution of statements, branches, conditions, subroutines, and pod.

Perhaps one day this will even lead to test-driven test development for those of us who are too lazy to do test-driven development itself -- i.e. what's the minimal amount of test suite I need to write to actually exercise the code I've already written?

[Ovid]

Excellent suggestion. The question of "what do I test?" should always be answered with "what have you tested"? and Devel::Cover does a great job of that. I've wowed coworkers with its HTML output :)

<malden type="karl">Devel::Cover. Don't leave home without it.</malden> (have I just dated myself?)

[stvn]

Ovid

I am actually running some of my tests through Devel::Cover right now, and and something just popped up.

What about on coverage for things like this:

    return wantarray ? @results : \@results;

Devel::Cover reports that I have only tested the @results return value branch. Should I test the \@results branch too, or is this being too granular?
-stvn

[Ovid]

You know, one thing that I forgot to mention, but it's vitally important to remember: if you find out you didn't test something, you might want to ask yourself if you have dead code. In your example, do you ever call that code in scalar context? (well, void context would also exercise that condition, but we'll ignore that) If not, you have dead code. If you do call it in scalar context, why are you overloading the return value? If you don't need to, perhaps this is an opportunity to simplify your code and thereby reduce the chances of bugs.

[Ovid]

Personally, I think something like that is too trivial to test -- until it breaks. If that's the only thing that Devel::Cover says you've missed, go ahead and toss the test in there if you like. Otherwise, concentrate on the "big ticket items" and only test that if it breaks (or if you feel like it. Some people are happy to test everything).

[stvn]

Yes, Devel::Cover is one of my favorite new toys too. I just actually showed it to my boss to demonstrate exactly what you are saying, how we can test test-coverage. He was really impressed, it was one more thing to help me in selling this way of testing.

Do you happen to have a link to that TPJ article? I actually read about this module on CPAN (saw it in the CPAN nodelet one day and was intrigued), but i would love to read the article.

-stvn

[xdg]

Unfortunately, TPJ is subscription-only now and doesn't seem to put archives online anymore since they went to a subscription model. (Even for subscribers! I can only find a link to the previous month, not historical months.)

[stvn]

xdg

Thanks for the update this looks to be a wealth of info on this. I was actually going to spend part of my day googling code coverage, but this is even better. If i could ++ more I would!

-stvn