Why Code Coverage?

While code coverage is not a strictly a necessity for most projects, it is highly desirable and adds very little overhead. Projects that are developed using an Agile methodology should definitely add a code coverage tool to its toolbox. No matter how well you think you are testing, there is always something you have missed. The first time I ran jcoverage against one of my projects, I was astonished at the little things I hadn't even thought about. In going through the report and thinking about it, though, it all made sense. Code coverage helps you become a better programmer. Like unit testing, code coverage can greatly improve the quality of your projects. You may be thinking "I've only got a 10 file project, why should I use code coverage?" I would counter with these reasons:

1. Small projects often turn into bigger projects as people make requests or new functionality is added.

2. You may move on, leaving the project, and someone else will have to pick the project up. By adding code coverage you ensure that what you have written is properly tested and that any changes future developers make will also have to be tested. This ensures that they write code that is properly tested .

3. Agile projects are constantly refactored to make them better. By using a code coverage tool you ensure that your refactorings are properly covered through your tests.

Code coverage is something that can become invaluable for a larger project. If your project has been performing unit tests for awhile, code coverage can illuminate holes in your tests so that you can go back incrementally and fix those tests until you achieve 100% coverage. Code coverage isn't an all-or-nothing deal. Like unit tests, it can be added at any time to ensure a higher-quality , better tested, and easier to understand application.

How does it work? Coverage analyzers add instrumentation. There are three types of instrumentation that can be added: source code instrumentation through a code pre-processor, byte-code instrumentation through a tool like cglib, and running code through a modified JVM.

Byte-code manipulation/enhancement occurs is the process by which a program takes the class file that your compiler produces and inserts new code into your methods . The inserted code could be aspect- oriented in nature, like adding a logging call into each method, or the code might enhance your class by dynamically adding properties to it. Bytecode enhancement appears to be gaining popularity for a wide variety of tasks . Currently you will see a type of enhancement in AspectJ (http://www.eclipse.org/ aspectj) that takes custom aspects and merges them with existing code after the code has been compiled. Tapestry uses bytecode enhancement through JavAssist (http://www.csg.is.titech.ac.jp/~ chiba / javassist/) when it automatically extends abstract classes and provides implementations of abstract methods you have declared, thereby simplifying the development process.

Until bytecode manipulation becomes more standardized, however, we may run into future problems with doing too much to pre-compiled classes. Some projects are already colliding and will not work together properly. For example you may have difficulty running jcoverage on classes that have had aspects added to them through AspectJ.

Types of Coverage

There are several types of code coverage that tools offer these are:

• Statement or line coverage: Indicates the degree to which individual statements are getting executed during test execution.

• Basic block coverage: Considers each sequence of non-branching statements as its unit of code instead of individual statements.

• Branch coverage: Indicates whether decision points such as if and while statements are executed through their corresponding branches with the tests.

• Path coverage: Indicates whether each possible path from start of the method to the end of the method is getting exercisedthis is different from Branch coverage in that Branch coverage considers each individual branch, whereas Path coverage looks at the logic paths altogether.

• Function coverage: Indicates whether each function is called during the test.

• Race coverage: Indicates when multiple threads are run what resources are shared amongst the threads and can indicate a possible race condition.

• Relational operator coverage: Iindicates the amount of coverage you have on operators such as a < 4; for instance, have you tested all the possibilities (such as 2, 3, 4, and 5)?