The NetBeans Unit Tests Code Coverage Plugin has been around for several versions of NetBeans. It measures code coverage statistics and displays annotated & highlighted lines in the Source Editor in each class that were executed by unit tests. In a recent release of the plugin, it also provides a report that shows overall, package, and class-level statistics. This article provides a quick overview of code coverage, why it is important, and what the NetBeans Unit Tests Code Coverage Plugin provides. I’ll also cover some pros/cons of the plugin.
Overview of Code Coverage
To quote myself from Chapter 16, Using Code Coverage Tools, of my book, Pro NetBeans IDE 5.5 Enterprise Edition (Apress, March 2007) :
You know that it is important to write accurate and effective tests for your code. But how do you measure the effectiveness of your tests? In a perfect world, you would write a test for every class, every method, and every line of code. Depending on the complexity of your code base, this may be easy or extremely difficult.
How do you know when you’ve written enough tests? If you have 200 tests for your code, and they all pass, then you’re finished, right? Not necessarily. You’re finished writing tests only when you know for a fact how effective your tests are. Since testing often involves visual analysis by programmers and code-based test cases, it’s difficult to know if 100 percent of your code has been tested. This is where code coverage tools come into play.
The first and obvious benefit of using a code coverage tool is being able to measure the coverage of your test cases (and, by association, the test case effectiveness). Untested code can lead to bugs, and bugs lead to many other problems.
Code coverage tools also help you identify areas in your code that are dead or unreachable. Suppose you have written test cases for all the public methods in your code. If your code coverage tool identifies one or more methods with private-level access that have never been executed, then you may be able to remove those methods from your source code. You can then use the NetBeans Safely Delete refactoring to check the method and make sure it is not called by any other code.
A good code coverage tool not only tracks if each line in each method was executed, but also how many times each line was executed. Using this data and the knowledge of what lines were and were not executed, you can understand the flow of program functionality and rearrange code blocks accordingly.
The NetBeans Unit Tests Code Coverage Plugin does not provide access to some of the information mentioned above (such as number of times each line was executed). However, it provides enough of the basic features you will need to be quite useful. Internally, the plugin depends on the Emma code coverage library.
Code Coverage tools like Emma and Cobertura (one of my personal favorites) typically work by instrumenting classes (inserting extra byte codes). The instrumented classes are then executed instead of the original un-instrumented classes. The inserted byte codes in the instrumented classes then collect different bits of data and deposit them in a file for later analysis.
Getting Started
As of the official release of NetBeans 6.1 Beta, the update centers contained a slightly older version of the code coverage plugin. I would suggest going to the official NetBeans code coverage plugin site and download it using the prominently displayed button labeled “Download Code Coverage Plugin”.
Use the Plugins Manager to install the NBM file. Go to the Downloaded tab and click the Add Plugins button. Accept the license, click Next a few times, and you should be all set.
Once installed, you need to activate code coverage on a per-project basis. For this article, I have a standard J2SE Java Library project. In the Projects window, right-click the project name, and you should see a Coverage submenu. It contains the following options :
   Activate Coverage Collection: When clicked activates code coverage collection for the selected project. This will also generate the file nbproject/coverage.properties and coverage/emmascript.xml, which are covered below.
   Deactivate Coverage Collection: When clicked deactivates code coverage collection.
   Show Project Coverage Statistics: When clicked displays a tab in the Source Editor showing the accumulated statistics collected by the plugin for the selected project.
 Files Generated By Activating Coverage Collection
As previously mentioned, several files are generated by activating coverage collection.
The nbproject.properties file contains several parameters used by the plugin such as :
   coverage.activity=ON
   project.type=java
   coverage.templateFile=coverage/template.emma
   coverage.coverageFile=coverage/coverage.emma
The first parameter obviously indicates whether the coverage collection is active or inactive. The second parameter identifies the type of NetBeans project, and the last 2 parameters identify the paths to specific files used by the plugin.
The coverage/emmascript.xml file contains Ant targets for executing the instrumentation of the project class files.
<?xml version=”1.0″ encoding=”UTF-8″?>
<project basedir=”.” default=”echoit” name=”Coverage Tasks”>
   <target name=”echoit” description=”test target”>
       <echo message=”Test succeeded.”/>
   </target>    Â
   Â
   <target name=”instr” description=”Instrumenting jars”>
       <echo message=”Instrumenting started.”/>
      Â
       <java classname=”emma” fork=”true”>          Â
           <classpath >
               <pathelement location=”${emma}”/>
           </classpath>
           <arg line=”instr -verbose -m overwrite -cp ‘${jarfiles}’ -outdir ‘${output.dir}’ -outfile ‘${output.dir}/template.emma’”/>
       </java>
       <echo message=”Instrumenting done.”/>
   </target>
   Â
</project>
 The instr target runs the main emma class passing it several arguments to overwrite the application JAR file with a JAR file of the project’s instrumented classes.
Creating Sample Code
First, create a simple Java Class like this :
public class StringUtils {
   public static String tryIntToString(int numLoops) {
       StringBuffer sb = new StringBuffer();
       for (int i = 0; i < numLoops; i++) {
               sb.append(String.valueOf(i));
       }
       return sb.toString();
   }
}
 It is basically a ‘hello world’ class that takes in a counter variable, numLoops, instantiates a StringBuffer, and loops appending an int converted to a String into the StringBuffer. The method then returns the value of the StringBuffer.
To test this method, create a JUnit test. Right-click the class listing in the Projects window and select Tools >> Create JUnit Tests (or press Control+Shift+U). Select your preferred JUnit version (4.x in this case) and the various other JUnit settings you are prompted for. Once created, I implement a basic test case for the StringUtils class passing in a value and setting the expected return.
public class StringUtilsTest {
   public StringUtilsTest() {
   }
   @BeforeClass
   public static void setUpClass() throws Exception {
   }
   @AfterClass
   public static void tearDownClass() throws Exception {
   }
   @Before
   public void setUp() {
   }
   @After
   public void tearDown() {
   }
   @Test
   public void testTryIntToString() {
       System.out.println(”tryIntToString03″);
      Â
       int numLoops = 10000;
       String result = StringUtils.tryIntToString(numLoops);
       int expectedResult = 38890;
      Â
       assertEquals(expectedResult, result.length());
   }
}
(more…)
