JCover - FAQ

*Getting Started*	TOP
1. *How do I get started?*
Please see JCover Quickstart in the help documentation.
2. *What are the platforms in which JCover is supported?*
Windows 95/98/ME/NT/2000/XP (See System requirements in help documentation).
3. When JCover starts up, I get a message to the effect that Java Runtime 1.2 is required, even though I have JDK 1.2 installed on my system. Why is JCover unable to detect my runtime?
Make sure that your JDK Bin directory is specified in the PATH. If you are able to invoke java or javac from command line, then you should not encounter this problem.
4. With what versions of JDK does JCover work?
It works with all VMs that are Java 2 compliant. One of the requirements for Java 2 compliance is that the VM should implement the Java Debugger Interface. JCover uses this interface to collect execution coverage information. Refer to topic JDK versions supported by JCover in help documentation for further information.
*Coverage Analysis*	TOP
5. Why is coverage analysis important?
Coverage analysis has the following benefits: We can determine if our test suite is adequate. A test suite that achieves 65% statement coverage is hardly adequate. We cannot be confident of our product's quality with this much coverage. This figure prompts us to enhance the test suite. We can identify redundant test cases that are not useful either in increasing code coverage or in finding new bugs. Fine tuning a test suite has immense benefits during regression testing. We can find out if there are regions of code that cannot be exercised at all, and hence can be cleaned up. We sometimes find that an application has code to support a feature that was discontinued in an earlier release of the product! Although test cases are normally generated from the specification, coverage analysis helps us in identifying areas that require further test focus.
6. What are some of the coverages typically found useful?
There are several types of coverages discussed in the research literature. Among these, the following are popular: Statement coverage, Condition coverage, Decision coverage, Condition /Decision coverage, Multiple condition coverage, Loop coverage. Even among these, Statement and Branch coverage are the most common. Some other coverages are Call-pair coverage, Path coverage and Data-flow coverage.
7. *Is there a difference between "Statement Coverage" and "Line Coverage"?*
It is generally believed that statement coverage is the same as line coverage. This might be true for programming languages such as Fortran and COBOL, but is debatable in the context of languages such as Java. In Java, we could define multiple statements on the same line, or split a statement across multiple lines. If a coverage analysis tool gathers line coverage for Java, how can it handle the following case correctly? class TestClass { public static void main(String[] args) { f(); g(); } void f() { /* body / } void g() { / body / } } The main* method contains two statements - one call to f() and another to g(). What happens if call to f() succeeds, but call to g() fails at runtime? Will the line-based coverage tool report this correctly? JCover uses the definition of statement as given in the Java Language Specification, so when it says for example, 100 statements were covered, there is no ambiguity.
8. Is "Branch coverage" important?
Most practitioners strongly recommend that branch coverage be taken into account in addition to statement coverage. The reason is easy to understand. Consider the following code: class TestClass2 { public static void main(String[] args) { if(args.length > 0) { System.out.println("Args available"); } System.out.println("Completed"); } } If a tool only supports statement coverage, it cannot determine whether the code was tested for the case where command line argument was not supplied (i.e., args.length == 0). This is the classic null else problem.
9. In that case, why should we restrict only to Statement and Branch coverage?
When we perform testing, we usually set some coverage objectives, and declare testing to be adequate if the objectives are met satisfactorily. What coverage measures we use depends on various factors such as their acceptance in the industry and tool support. If you believe that your testing strategies call for the more exotic measures such as data-flow and path, you should go ahead and use them. After all, testing is a serious activity, and anything that improves the quality of the software is quite welcome.
10. Will there be a performance hit when I run the coverage-enabled application?
When an application is run with coverage analysis enabled, extra code gets executed at runtime to gather the critical parameters required for accurate coverage reporting. Depending on the coverage implementation technology as well as the nature of the application, performance deterioration is to be expected.
11. Does 100% coverage indicate that my application is bug free?
Certainly not. Coverage measure is just an indicator of how well various parts of your program were exercised during testing. If some parts of the code were not covered during testing, it might indicate a poor testing strategy, among other things. For example, the following simple program easily achieves 100% statement coverage, but is buggy if the program specification says it must print the larger of two positive integers specified as commandline arguments. class Buggy { public static void main(String args[]) { System.out.println(args[0] + args[1]); } } So a test team cannot release a piece of software to the client just because 100% statement coverage was achieved.
12. Should I always try to achieve 100% coverage?
Getting 100% coverage is a lofty goal, but rarely achieved in practice. Remember also that when we talk about a coverage percentage, it is with respect to some program element such as statement, branch, etc. Achieving 100% statement coverage may be easier than achieving 100% branch coverage. Achieving 100% path coverage is impossible except in trivial cases. If 100% coverage of some element is not achieved during testing, it may not be a panicky situation in itself, but may warrant a closer scrutiny of test cases and the code to rule out dangerous pathology.
13. What types of coverage does JCover support?
Statement, Branch, Method, and Class coverage.
*Project*	TOP
14. Do I need to have Java source files for doing a coverage analysis using JCover?
No, JCover can work with both Java source file and Java classes. But, if you have source files we recommend that you add them to JCover project instead of the classes.
15. Should all the Java files or classes in my application be added to JCover project to perform coverage analysis?
Although JCover does not require this, you would normally include the entire application source (or classes) so that coverage information for the whole project is gathered by JCover. The short answer is, if you want JCover to generate coverage data for a set of classes, Java sources (or classes) for those classes must be added to JCover project.
16. Project with classes takes too much time to load. Why?
Make sure you have set the classpath right. If the classpath has directories such as c:\ it will take a very long time to get the list of all classes in the classpath.
17. How do I integrate JCover in my build process?
Please see Integrating JCover in your build process in the help documentation.
*Instrumentation*	TOP
18. My project has no source files. Should I still instrument the project?
Yes, you need to. During instrumentation, JCover records information about classes, methods and statements in the project in a Project Definition file (.def). This file is later used or interpreting the coverage data generated during execution. If your project has source files, JCover processes them and generates instrumented source files. The def file has to be generated irrespective of whether your project has source files or not. Hence you need to instrument the project. Note that if you have added classes to the project those classes are not modified or no new (instrumented) versions of the classes are generated. You can execute the original set of classes.
19. My project uses resources such as images, XMLs, config files etc. When I instrument the project, new set of source files are created under instrument directory. I have to copy the rest of files to the instrument directory before executing the application (complicates the build and execution process). It would have been simpler if JCover had an option to overwrite the original source files.
The simplest solution is to redirect the class files to the original source directory during compilation of the instrumented source. To do this, you have to add the following compiler option. javac -d c:\myproject\src ... Use the Project Settings dialog to modify the options passed to the compiler. You can now continue with the rest of your build process (for instance, create a Jar) from your source directory instead of copying rest of your application to the instrument directory. Make sure that while executing your application the JCover specific options are passed to the VM.
20. Why does JCover generate the project definition file in a separate step (instrumentation)? Why can’t it do it during execution? That way you can eliminate project definition file and include that information as part of the coverage data file (like what some other coverage tool does).
The project definition file contains meta-information about the project’s classes, methods and statements. It does not change with every run. Hence recording it during every run is unnecessary. Not all the classes in your project will be loaded during every session of your program. The project definition generated based on the classes that were loaded during execution (as other coverage tools do) will not be complete. For instance, each run may report a different total number of classes, methods and statements. Since each run has its own project definition (which is different), the coverage tool will not be able to report project level metrics with any accuracy. JCover solves this problem by letting you define the project (the source files and the classes). It then generates a project definition file during instrumentation and uses it as a reference for interpreting coverage data generated during execution.
*Execution*	TOP
*21. Should I always execute my application from the JCover environment?*
No. If you wish, you could launch your application (after instrumenting and compiling) outside of JCover, as you might do in the case of normal Java applications, e.g., from the command line Windows start menu from another application using the Java Invocation API In some cases such as EJB servers, the application might have to run on a machine different from the one where JCover runs, so you cannot launch the application from within JCover. In such cases, you will have to pass certain special arguments to the JVM. Refer to the topic Launching your application from command line in help documentation for more details.
*22. When I execute my application from JCover I get the following message. How should I proceed?*
Unrecognized option: -classic Could not create the Java virtual machine. The Java runtime you are using does not support the classic VM. For instance JRE 1.3.1 and above does not support classic VM. You can, Change the JVM options to -hotspot -Xdebug –Xnoagent, (for JDK1.3.1 and above) or Change the Java runtime to the absolute path of Java executable installed as part of JDK (like, C:\jdk1.3.1\bin\java.exe). Since the Java Runtime installed under the JDK directory provides more debug information, it is always a good idea to use it (instead of the one installed under JavaSoft\JRE) during development and testing.
*23. When I execute my application from JCover, I get a class not found error. How should I proceed?*
Exception in thread "main" java.lang.NoClassDefFoundError: Main Check whether the class path is correct. Make sure that the class you are executing is available in the class path. Check whether the Working Directory is set correctly.
*24. When I execute my application from JCover or using the batch file, it does not run as expected. What can be the problem?*
Check the command line. the classpath JVM options main class and arguments the initial directory the option to load JCVRun If every thing looks OK, try the following, Remove the option to load JCVRun from the command line. That is, remove "-XrunJRun:insfile= " from the command line. The rest of the command has nothing to do with JCover. Run your (instrumented) application from the same directory. If your application now runs as you expect then there is a problem with JCVRun or its options. If it doesn't, check classpath etc., and make sure your application runs without JCover. Then add JCover specific option (-XrunJRun:...) and see whether it runs now. Refer to the next question for more info.
*25. Although my instrumented application runs correctly, the coverage data file contains no information. What could be wrong?*
One cause for this is that you might be running the VM without specifying some required options. Make sure that you are running the correct version of VM (Refer to Software Requirements in help documentation). Make sure that the options –Xdebug and –Xnoagent are passed to the VM. If you are using the classic VM, make sure that the option -XDjava.compiler=NONE is passed to the VM. Check whether the option to enable coverage "–XrunJCVRun:…." Is correctly passed to the VM. On application startup, the coverage agent displays a "coverage enabled" message. Make sure that this message is displayed when you run your application. Add verbose=true option to the JCVRun and check whether JCVRun displays a 'coverage enabled' message for all the classes for which coverage is enabled. Check whether the following output is written to the DOS prompt when your application exits. *** Coverage data successfully written
26. I added source files to my JCover project, instrumented it and executed it with coverage enabled and the dat file was generated as expected. When I loaded the coverage data file, the statements highlighted by source coverage view do not make sense (see image below)?
It is likely that you have executed the original classes instead of the instrumented ones. The runtime agent cannot distinguish between instrumented classes and your original classes. It collects coverage information based on the classes that are loaded by the VM. When you instrument the project, a project definition file is created based on the instrumented files. If you execute the original classes the line numbers in coverage dat file will be different from that recorded in the project definition file. Because of this inconsistency, incorrect lines are highlighted. You can try the following: Check the class path to ensure that the instrumented classes are ones that are executed. It is a good idea to remove reference to the original classes’ directory or Jar from the class path.
*27. Can I use JCover to perform coverage analysis for applets?*
Yes, but only with AppletViewer (Refer to topic Executing from command-line in help documentation).
*28. Can JCover be used in case of EJBs, servlets etc?*
For performance reasons JCover emits instrumentation code in your source minimally, but relies on native code to attach to the JVM when your application is running. JCover uses standard runtime switches to register itself with the JVM. If the host environment (EJB, Servlet Engine, etc.) supports these switches, then it should be possible to use JCover in that environment. Refer to topic Using JCover with Application Servers in help documentation for more information.
*Coverage Data Files*	TOP
*29. Can I take multiple snapshots of coverage information during a single session of my application?*
Yes, you can. Refer to the topic Monitoring Coverage Gathering in help documentation for more information.
30. Does JCover provide a way for merging the coverage information generated during multiple test runs?
Yes. Everytime you run the application, the coverage information is saved in a different coverage data file. After the application terminates, you can the load the different coverage files whose merged information you require. JCover automatically creates a union of these data and displays the correct coverage (Refer to topic Dat Merge in help documentation).
31. When I execute my application from JCover, on application exit, JCover automatically merges the coverage information for this run with the previous runs and displays the merged information in a spreadsheet view. I am interested in the coverage for the last run and not the union of all runs. How do I view it?
On application exit, the coverage dat file for the last run is added to the project and is listed in the DatView of the Workspace Window. Double click on that dat file to view the coverage metric spreadsheet for the last run (you can do this for any dat file).
32. JCover offers great flexibility by allowing me to view coverage information for union of all the runs, a particular run, or any combination of runs. However, given a view, I need to know which dat files produced it. How can I find out?
The property window lists the dat file(s) that were merged to produce the view. To display the properties of a coverage view, select Properties Window from the View menu and click on the view for which you want to see the properties. The Dat files (corresponds to a test run) used are listed in the Dat Files tab of the Properties window.
*33. What kind of reports does JCover generate?*
JCover can generate Text, XML, and HTML reports of coverage information. In addition, JCover provides various charting options, as well as the ability to export coverage data to a database.
*34. When I try to export coverage data to database, JCover reports an error. Why?*
You may not have Microsoft’s DAO (Data Access Objects) installed on your machine. Contact Man Machine Systems to get the installer for DAO.