News

2007

2006

2005


How We Support You
  • 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 (at) codign dot 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.

Select Features
CoViewDeveloper CoViewManager
Immediate Metric Analysis One-Click Coverage and Testability Overview
User-defined Testability Thresholds Prevent Compilation if Code Exceeds Metric Thresholds
User-defined Testability Severity Levels Branch Coverage
Advanced JUnit Wizards Export to 3rd Party Products
Auto-generated Proxy Code to Test Private Methods Detailed Violations in Problems View
Zero Footprint on all JUnit tests JUnit Management Metrics
True Path Coverage Analysis Advanced Testability Preferences for Development Projects
Support for DbUnit and HTTPUnit Metric Violation Notification
Create JUnit tests for RCP, Web & Plug-ins Easy Installation & Setup
Detailed Path Analysis and Display Low Overhead
CoView Screenshots

DemoLorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

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.