Getting Started with CoView and Comet

Installing CoView

CoView installs as a native Eclipse plug-in.

1. From Eclipse, select Help > Software Updates > Find and Install
2. Next, select Search For New Features to Install
3. Then select New Remote Site
4. Provide a name, like CoView
5. Use the URL http://www.codign.com/updates
6. Go through the rest of the installation and restart Eclipse

Installing Comet

Comet is distributed as a .jar file for either command-line use or Ant integration.

Comet requires JDK 1.4 or greater, Ant 1.6.1 or greater, and a valid license file.

You can download comet.jar here.

CoView License File

1. Register to get your license file.
2. Copy/paste your license file (check your email) and save it to a file (like coview.lic). Remember where you save it.
3. Next,in Eclipse, select Preferences > Codign.
4. In the License file location, enter the full path and license file name (or just browse for it).
5. In the Data location, specify a directory where CoView can store some data files.

Comet License File

1. Register to get your license file.
2. Copy/paste your license file (check your email) and save it to a file (like /Users/jponczak/coview/coview.lic). Remember where you save it.
3. In your build.xml file, or via the Comet command line, make sure the "license" flag points to the correct path/file. For example: license="/Users/jponczak/coview/coview.lic"

Measuring Code Testability

1. First, you pick your metrics, thresholds and severity levels. In Eclipse, select Preferences > Codign > Metrics Thresholds.
2. Next, let CoView parse your code. In Eclipse, right-click on a package or class and select CoView > Show Testability Summary .
3. Next, do some development in the CoView Editor. If you exceed any of your thresholds, decorators (similar to syntax errors) immediately appear. To open the CoView Editor, right-click on a class and select Open With > CoView Editor.

Generating JUnit Test Cases

1. In Eclipse, right-click on a class and select CoView > Create CoView JUnit Tests and answer some questions.
2. Once the JUnit test case is generated, you can run it by selecting Run As > CoView JUnit Test or by clicking the [ ] in the CoView JUnit Developer view.
3. You can easily add more tests from the CoView JUnit Developer view. Right-click on a class and select Source > Add Test. From here, you can double-click on a path, see the highlighted path in your code, and modify the JUnit parameters and assertions as necessary.

Measuring Coverage

1. To get branch coverage for your JUnit tests, right-click on a package, JUnit test case or test suite and select Run As > CoView JUnit Test
2. To get path coverage for your test cases (not ones generated by CoView), right click on your JUnit test case and select Open With > CoView Editor
3. Click on the [ ] (located on the left column of the CoView Editor) and select the method under test from the list of methods.
3. Click on the [ ] (located in the CoView JUnit Developer view) to run your test.

Comet + Ant

Option/Use		Description
stoponerror="false"		Prevents ant task from completing if the metric threshold exceeds your input and the metric has a severity of error. Defaults to false.
errorsonly="false"		Reports only methods that exceed your metric thresholds defined with severity of error. Defaults to false.
includejunit="false"		Include JUnit classes in metrics analysis. Default is to skip all JUnit test classes.
source="1.5"		Java version to use when analyzing source code. Valid values are Java 1.1 to Java7. Default is Java 1.4.
dir="/Users/anonymous/workspace/CarRental/src"		Directory where the source code can be found.
html="true"		Creates a HTML report called report.html.Default is false.
log="./log.out"		Outputs all comet information to the specified log file.
license="/Users/anonymous/codign.lic"		Specifies the location of the license file. Comet requires a valid license file, available here.
classpathref="carrentalpathid"		Classpath ID, defined in a separate <> target
include name="*/.java"		Specifies the type of file to be analyzed within the dir option
exclude="*/Test.java"		Specifies the files to be ignored during analysis.
thresholdname="parameters" value="4" severity="error"		Identifies the metric, threshold and severity level. For this example, any method with greater than 4 parameters will be flagged as an error. If stoponerror="true", the build will stop. Valid metrics are parameters (parameters), exceptions (exceptions), lines of code (loc), cyclomatic complexity (cc), paths (paths), static invocations (staticinvocations), anonymous classes (anonclasses).

Build File Example

*. Sample code, including a build file that contains a Comet task and a report are available here.
*. This example requires Ant 1.6 or later. Instructions for setting up your environment are also available.

CoView Help

Complete CoView help is available here.

Comet Help

Complete Comet help is available here.

Testability Metrics

Metric	Impact
Parameters	Each parameter added to a method's signature increases the number of possible ways that method can be invoked, eventually creating an unmanageable combinatorial problem. By limiting the number of parameters to three or fewer, you can easily increase the testability of your code.
Exceptions	Each thrown exception represents a distinct error condition that must be tested, and error conditions are very hard to test. Keeping the number of thrown exceptions to three or less greatly simplifies your testing effort.
Cyclomatic Complexity	Cyclomatic Complexity (CC) is a measure of the decision logic in a method. The more decisions your method has, the more ways it will behave. Keeping the number of CC paths to 10 or less greatly reduces the risk of defects as well as increases the overall testability of your code.
Lines of Code	One of the oldest and simplest metrics used to measure a method's testability. A shorter method is easier to understand and test. We suggest limiting your methods to 50 lines of code or less.
Paths	This metric looks at distinct data paths. Data paths are paths that link a data element's definition to its use. In other words, if you define a data element, you should use it, and if you use it, you should test it. Data paths often overlap with Cyclomatic Complexity paths, which is why we suggest a similar threshold of 10.
Static Invocations	Methods under test invoke methods from external classes, and these external classes can usually be mocked or dummied up to behave exactly as required for an individual unit test. Static invocations of external methods often have an unchangeable behavior that thwarts even the best testing effort. Avoid this unnecessary coupling to external classes, and keep your external static invocations to a minimum.
Anonymous Classes	Anonymous classes make unit testing difficult because they exist only within the method under test, and cannot themselves be unit tested. Although anonymous classes are convenient (especially for GUI programming), their lack of testability and mockability can hinder your testing effort.
Branch Coverage	A high coverage percentage indicates a strong testing effort and ensures that a greater percentage of decision logic has been fully tested. Keeping the other testability metrics low will make it easier for you to have a high branch coverage metric, giving you peace of mind that only high coverage can bring.
Number of JUnit Tests	In a perfect world, you should have one unit test for every decision, data element and boundary condition in your method. In the real world, 100% coverage is not always possible. The number of actual tests possible will vary by method and project, but having even a single JUnit test can flush out otherwise hidden problems.