Code overlay Test-code Coverage Testing with eclemma-use article

testing Java programs with Eclemma

to experiment with the characteristics of Eclemma, we first build a Workspace in Eclipse to create a name called New Java Project for Test . Emma. Next, we'll create a HelloWorld class in which the code looks like this:

Package Test.emma;

public class HelloWorld {

/**
* @param args
*/
public static void Main (string[] args) {
int rand = (int) (Math.random () *100);
if (rand%2==0) {
System.out.println ("Hello, world! 0 ");
}
Else
System.out.println ("Hello, world! 1 ");

int result = Rand%2==0? Rand+rand:rand*rand;
SYSTEM.OUT.PRINTLN (result);
}
}

Next, we run the Helloworld.main () function via Eclemma.

Figure 3 Overwrite test for Java application

After the execution, we are editing the Helloworld.java window as follows:

Figure 4 The results of the overlay test

In the Java editor, Eclemma uses different colors to mark the source code test. Where the Green line indicates that the line code is fully executed, the Red section indicates that the line code was not executed at all, and the yellow line indicates that the line code was partially executed. A yellow line usually occurs when a single line of code contains a branch, such as 16 lines in the previous illustration showing yellow. Because there is a randomly identified branch in the program, the Reader's window may be slightly different from here (11 or 14 lines with only one red line).

In addition to coloring directly in the Source edit window, Eclemma provides a separate view to count the coverage test rate of the program.

Fig. 5 The coverage test rate of the viewing procedure

The Coverage view provided by Eclemma can be layered to show the coverage test rate of the code, and the information in the above figure shows that we covered about 68.6% of the code for the HelloWorld operation.

It is often difficult to overwrite all of the code in a single run, and if you can combine the coverage data from multiple tests to view it, then it is easier to master the test results of multiple tests. Eclemma provides such a feature. Now, let's repeat the overlay test for HelloWorld several times. We note that the Coverage view always displays the most recently completed coverage test. In fact, Eclemma saved all the test results for us. Next, we'll use the Coverage View Tool button to cover the results of the test multiple times.

Figure 6 toolbar buttons for combining multiple overlay test results

When we run Coverage more than once, we can click the toolbar button shown in the previous illustration. A dialog box is then ejected to allow the user to select an overlay test that needs to be merged.

Figure 7 Selecting the overlay test results that need to be merged

After the merge is complete, we can observe that both the Java editor and the Coverage View show the results of the merge:

Figure 8 View the combined overlay test results

From the above illustration, we can see that by running the overlay test multiple times, our code eventually reaches 91.4% of the test coverage. Interestingly, the third line of code in the diagram is marked red, and this code is actually not executable. The trick is that we don't generate an instance of any HelloWorld class, so the default constructor is not invoked, and eclemma marks the overwrite state of this particular code in the first line of the class declaration.

Advanced Features of Eclemma

if Eclemma can only test the test coverage of the Java application, it does not provide much enhancement relative to the command-line version of Emma. Instead, Eclemma offers a number of features that are tightly integrated with Eclipse. It can not only test the Java application, but also calculate the JUnit Unit tests and coverage of Eclipse plug-in tests. From the figure below we can see that Eclemma currently supports four types of programs.

Figure 9 Configuration page for Eclemma

To understand how Eclemma gets coverage of test data, we need to have a preliminary understanding of Emma first. Typically, the code coverage test Tool needs to modify the code being executed. And Emma offers two ways to do it. Pre-insert mode: before you measure the program, you need to modify the class file or jar file with the tools provided by Emma. The code after the modification is complete can be executed immediately. The results of the overwrite test will be stored in the specified file. Instant Insert mode: Instant insert mode does not require modifications to the code in advance. Instead, the changes to the code are made through a custom-Emma class loader (loader). The advantages of this approach are obvious, we do not need to make any changes to class or jar files. The disadvantage is that we need to use Emma's command Emmarun to execute the Java application in order to get the test results.

the advantages of using instant Insert mode are obvious: class files and jar files are not modified. The pre-insert pattern is more widely used, and for some code that needs to be embedded in the framework (for example, EJB), we can only use the pre-insert mode. Eclemma only uses Emma's pre-insertion mode to work , but Eclemma lacks the capital to create a copy of the class file and jar file in the temp directory to modify it, so in workspace class and J The AR file is still intact. While it sounds good, because you need to modify CLASSPATH to use the modified class and jar files, for applications that cannot modify classpath (such as Eclipse RCP and JUnit Plugin Test), we can only choose to modify Wo class file and Jar file in the rkspace. For the Java application and JUnit type overlay tests, we can select the "in-place instrumentation" Item in the configuration dialog to specify that the. class file and. jar in Workspace be directly modified. File.

Conclusion

This article introduces a simple example of the basic process of using ECLEMMA to cover tests. Eclemma allows software engineers/test engineers to easily review the coverage of the test and to present the results in an intuitive and concise manner to the developer.