Generate JUnit Tests, Improve Code Testability, Measure Coverage

  • Two Eclipse plug-ins and an Ant task that help developers and managers alike.
  • New! Comet for Ant Comet, available for Ant, lets you measure your metrics, your way during the build process. With Comet, you can verify how testable your code is before it gets to your QA team. It is well known that as code becomes more complicated, untestable and incomprehensible, QA, testing, refactoring and bug fixing will simply cost more. With Comet, you can control and predict your costs.
  • CoViewDeveloper helps developers improve the testability of their code, easily design and generate JUnit tests, highlight paths and measure path coverage. Whether you are local or global, using Test Driven Development or the more traditional code first, test second approach, CoViewDeveloper makes development and unit testing a pleasure.
  • CoViewManager helps managers define quality standards and check coverage before code is released into production. Byletting users choose the metrics they want to analyze, CoViewManager measures quality on your terms. CoViewManager is a great tool to help new developers get up to speed, control your offshore development team, and give you the insight into code you truly deserve.

What is CoViewDeveloper?
  • CoViewDeveloper is an Eclipse plug-in that promotes testable code by designing and creating JUnit tests and measuring path coverage. With the focus on how data flows through a method, CoViewDeveloper walks you through every step of the way. CoViewDeveloper is ideal for organizations, consultants, developers and students who are interested in a quick, affordable affordable way to improve unit testing, metrics and coverage.
  • Using CoViewDeveloper is easy. Simply pick your metrics from the list we provide, select your threshold and severity level. As you code, decorators appear every time you exceed your metric thresholds. When it comes to testable code, you are in control ... but that doesn't mean we can't help. CoViewDeveloper measures many metrics, including cyclomatic complexity, coverage and JUnit statistics.
  • CoViewDeveloper also helps create JUnit tests. Simply select your method and start the CoView JUnit Wizard. Answer some questions and some advanced JUnit stubs (often times complete JUnit tests) are created. Through our Eclipse views, you can then go through your method, path by path, and figure out which code paths you want to test. Run the tests through the CoView JUnit Runner, and you can easily see which paths in a method were tested and which ones weren't. If you want to do more unit testing, simpley pick a new path and the CoViewDeveloper wizards will create unit test templates for you. You have to fill in some blanks (like parameters and assertions), but most of the unit test is created automatically.
  • In addition to JUnit support, CoViewDeveloper also has wizards for HTTPUnit and DbUnit, as well as support for abstract classes and private methods.
What is CoViewManager?
  • CoViewManager tells you how testable your code is. But CoViewManager doesn't simply display the metrics in raw or trend format (lots of other products do that). Rather, CoViewManager lets you pick the metrics you are interested in, lets you identify the threshold and severity (error, warning or ignore), and then displays all code that exceeded your specifications. By setting the threshold and severity for each metric, you can set code expectations but not impact developer creativity. This is an ideal solution for less-experienced developers or for managing off-shore development teams.
  • CoViewManager comes with 9 metrics that you can choose from, including cyclomatic complexity and coverage. Use one or use them all - it's up to you. For example, it is well known that methods with more than 10 cyclomatic complexity paths are harder to test and maintain than methods with fewer paths. With CoViewManager, you set the threshold for Paths to a number (like '10') and the severity level (like 'Error'). When a developer adds the 11th path, flags are immediately raised. The developer can either simplify their code or add a Javadoc explanation as to why it is necessary to have 11 paths. As the manager, when you run CoViewManager, you would see only the set of methods taht exceeded your threshold, removing many false positives.
  • Within the CoView Quality Manager view, you can easily see all methods that exceed thresholds and determine why that occurred. You no longer have to look at raw metrics and try to figure out what to do next. CoViewManager identifies methods that exceed testability thresholds as soon as they are written, letting you simplify the testing process while you're still coding.
Select Features
CoViewDeveloper CoViewManager Comet
Immediate Metric Analysis One-Click Coverage and Testability Overview Ant Integration
User-defined Testability Metrics, Thresholds and Severity Levels Prevent Compilation if Code Exceeds Metric Thresholds User-defined Testability Metrics, Thresholds and Severity Levels
Path Coverage Branch Coverage Low overhead/cost of ownership
Advanced JUnit Wizards Support 3rd Party Products Easy to implement
Auto-generated Proxy Code to Test Private Methods Detailed Violations in Problems View Pick the code you want to analyze
Zero Footprint on all JUnit tests JUnit Management Metrics Generate HTML or XML reports
Support for DbUnit and HTTPUnit Metric Violation Notification Supports JDK 1.4, 5, and 6
Create JUnit tests for RCP, Web & Plug-ins Easy Installation & Setup IDE Independant
Detailed Path Analysis and Display Low Overhead Simple and Effective
What is Comet?
  • Comet is an Ant task that calculates testability metrics at build time. With Comet, you can improve your code by making sure methods are within your metric boundaries.
  • Using Comet is easy. Simply add the Comet task to your build file, pick your metrics, and off you go. There are many metrics and options to choose from, including Parameters, Lines of Code, Cyclomatic Complexity, Paths, Static Invocations, Exceptions and Anonymous Classes.
  • Download the Comet Ant task today, get a license file and try it out.
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.