What is CoView?

CoView is actually two Eclipse plug-ins that work well together or can be used seperately. Both plug-ins are used to improve code testability, design unit tests, measure coverage, and provide managers with the right metrics in a usable format.
CoViewDeveloper is a more developer-centric plug-in, as the primary focus is to help developers create testable code and unit tests.
CoViewManager helps managers determine quality standards before code is written. By using commodity metrics, CoViewManager lets you determine which metrics you want to use, set a threshold, and determine the severity. In other words, you can objectively set everyone's expectations and make sure that code is written in a 'testable' manner.

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 an affordable solution that provides lots of value.
CoViewDeveloper begins by analyzing your code and unit tests. The analysis calculates metrics and also provides a visual representation of each path through a method. For complex code, the ability to see data flow down a particular path simplifies the unit test process because it is easier to create a unit test against a concrete set of inputs and expected outputs. Next, if you have any unit tests, CoViewDeveloper will try to figure out which unit tests executed which paths. Sometimes this is difficult, so CoViewDeveloper will prompt you to 'resolve' the methods under test - meaning, can you pick the unit test that is supposed to execute this particular method?
After that is complete, you can get a better sense of your true unit test coverage. You can easily see which paths in a method were tested and which ones weren't. If you want to do more unit testing, pick a path and CoViewDeveloper has a series of wizards that 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.
If your code or unit tests change, CoViewDeveloper will notify you as well, so you can make the appropriate changes.
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 lets you determine how to measure the testability of your code by looking at specific, industry proven metrics. But, CoViewManager don't simply display the metrics in raw or trend format (lots of other products do that). Rather, CoViewManager lets you pick the metric threshold and severity (error, warning or ignore), and then displays all code that violated that threshold. By setting the threshold and severity for each metric, you are providing realistic parameters around your developers' creativity.
CoViewManager comes with 9 metrics that you can choose from. Use 1 or use them all - it's up to you. For example, it is well known that methods with more than 10 logical 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. Hopefully, the developer will create a unit test as well.
With the Quality Manager view, you can easily see all threshold violations and determine why those violations occured. You no longer have to look at raw metrics and try to figure out what to do next. With CoViewManager, violations mean the code is not going to be easily tested, which is why you want to find out as soon as possible, like the second a violation occurs - not after the files have been checked in.

CoView Features

Lorem 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.

CoView Screenshots

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.