I saw this article on OnJava about so called Statement, Branch, and Path Coverage. The gist was that even if your code coverage was good, there could be different paths of execution that aren't being tested. This is obviously true, and I would think most programmers would roll their eyes and say "duh" to this.
The author offers up the Statement and Branch coverages as ways to analyze such a problem, but ultimately dismisses these methods as inadequate. He then offers up Path Coverage. In his section on Path Coverage he brings up two points:
Fortunately, you can use a metric called cyclomatic complexity to reduce the number of paths you need to test.
Ah, the magic phrase. It's the only thing that came to my mind when I read the title. The author then goes out on a limb and says:
Keep your code simple. The lower the cyclomatic complexity of your methods, the better.
He then describes how by determing the cyclomatic complexity, you can then enumerate the scenarios that need to be tested.
This guy's heart is in the right place, but massively enumerated test paths is the worst-case scenario. Just reduce the complexity. It's so much easier than writing thousands of test cases and the accompanying data. Not to mention that it actually improves your code. I'll go out on a limb and say that if you need to enumerate through many test cases because of high complexity, you're going to have bugs. It doesn't matter if you write all these test cases and all this test data. Unit testing can't always save poor design and/or bad code.
technorati tags:java, cyclomatic complexity, unit testing, metrics
No comments:
Post a Comment