Support & Download

Support is available for all CoView users. We strive to answer all questions and address all issues as quickly as possible. When reporting issues, please be as detailed as possible, including the steps to recreate as well as some sample code to reproduce.

How We Support You

Documentation is available here for Codign customers and those evaluating our software. Help is also available from within the Eclipse IDE.
Phone support is available for Codign customers and those evaluating our software. Phone hours are available Monday through Friday, from 8 AM EST to 8 PM EST. The phone number is (410) 244-8660.
Forum support is available 24 hours a day. Our forum lets you post questions, concerns and issues to share with other CoView users and evaluators. The forum is moderated. Posts considered unrelated or containing offensive language will be removed.
Email support is available. You can send us an email to support@codign.com.
In General when describing a defect or issue, please be as specific as possible. A code sample and set of steps to recreate the issue will let us address it that much faster.

Download and Licensing

Download CoView

Note that options vary slightly depending on which Eclipse version (3.1, 3.2, 3.3) you are using.

1. From within Eclipse, select Help > Software Updates > Find and Install
2. Select Find and Install
3. Select New Remote Site
4. Use URL: http://www.codign.com/updates
Proceed through the installation

Licensing

Your license key is emailed to you once you register.

1. Save the license file to a directory on your hard drive.
2. Open the Codign Preferences in Eclipse: Window > Preferences > Codign
3. Browse to (or enter) the license file location

You can verify installation and licensing if you can open the CoView Perspective in Eclipse: Window > Open Perspective > Other.

If you have any questions, please contact us at support (at) codign.com.

Articles & White papers

Articles

The Differences and Benefits of Path, Branch and Code Coverage

White Papers

Sample Code

Help & Documentation

CoView Help

Calculate Metrics

Action		Steps
Pick Your Metrics		Preferences > Codign > Metrics Thresholds
Run Your Report		Right-click on a package or class and select CoView > Show Testability Summary

Generating JUnit Tests

Action		Steps
Start the CoView JUnit Wizard		Right-click on a class and select CoView > Create CoView JUnit Tests and answer some questions
Run Your JUnit Tests		Right-click on the package or class and select Run As > CoView JUnit Test
Generate More JUnit Tests		From the CoView JUnit Developer View, right-click on a class and select Source > Add Test

Measure Branch Coverage

Action		Steps
Run Any or All Your JUnit Tests		Right-click a package, JUnit test suite or JUnit test case and select Run As > CoView JUnit Test

Want Path Coverage?

Action		Steps
Open Your JUnit Tests in the CoView Editor		Right-click on your JUnit test case and select Open With > CoView Editor
Relate the Test Case to the Method Under Test		Click on the [ ] and pick from the list of methods
Run Your JUnit Tests Through the CoView Runner		From the CoView JUnit Developer view, select the [ ] to execute your JUnit test case.

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.

Testability Metrics

Metric	Impact
Parameters	Having many parameters increases the complexity and time needed to properly unit test. Each parameter can have at least three states (true, false or null). Multiple parameters becomes a combinatorial and exponential problem, where ultimately a number of heuristics will be needed to create a set of valid unit tests. By limiting parameters to a manageable number, you can greatly increase the testability of your code.
Exceptions	While exceptions are typically good to have, too many increase the difficulty in unit testing. Throwing each exception in order to assert the results requires complicated environments to set up. Limiting exceptions to 2 or less will significantly improve the testability of your code.
Cyclomatic Complexity	Cyclomatic complexity (aka the number of logical paths within a method) is calculated based on the number of decisions. If the code has lots of decisions to make, then there is a greater chance of missing something. Think of cyclomatic complexity as a map showing you the different ways to get from Baltimore to Washington D.C. The more ways (or paths) you have, the more you have to test, and the more you have to test, the longer it will take and the greater the chance of not testing something. Limit your paths to less than 10 and you can control your code.
Lines of Code	Not much to really say here, except that the more lines of code you have, most likely the more you have to deal with.
Paths	This metric is different than cyclomatic complexity. Where cyclomatic complexity focuses on the inside logic of a method, this metric takes into account the paths that parameters and other data points travel down. It's simple to understand - if you define something, you should use it. If you use it, you should test it. These paths tell you what to test. Again, they should be limited to 10 or less.
Static Invocations	This one is bad. The more static invocations you have in your code, the closer to impossible the code comes to testing.
Anonymous Classes
Branch Coverage	This one is relatively arbitrary, but we recommend starting with a threshold of 50%. Focus on code that has high path count but less than 50% coverage.
Number of JUnit Tests	A simple metric, but one that is often overlooked. In a perfect world, you should have one unit test per path. In a realistic world, you should have one unit test for all methods that have more than 10 paths and at least one unit test per method for methods with less than 10 paths.