Recent changes to feature-requests

Correlation

2012-11-01T23:24:18Z

I'm guessing it would speed things up and look a little cooler if the correlation matrix resized to fit the window it was in. The boxes don't have to be that big.

passing vmargs from codecover testRunner to the JunitTestCas

2010-06-11T10:58:21Z

The vmargs I pass to the testRunner can be passed to the JunitTestCase .

My testcase requires jmockit to be initialized which I do with javaagent , but the vmargs I pass are not getting reflected in my testcase . Not sure if there is some way to get the vmargs to be set while running my testcase
java -cp bin;lib\junit3.8.1.jar;lib\JUnit-TestRunner.jar;c:\src\bin -methodsAsTestCases -javaagent c:\src\jmockit.jar org.codecover.junit3.swing.TestRunner com.testMyApp

Auto-enable codecover when choosing classes for coverage

2010-01-28T18:00:37Z

As of the current 10.0.0.8 version, you have to "enable" a project for codecover and declare which types of measure you want to use, before you the measurement will work. Nevertheless, you can check "use for coverage management" on classes or packages for non-codecover-enabled projects.

IMHO this is a usability flow, which tends to confuse new users. Here's my proposal: After checking "use for coverage management" in a not yet codecover enabled project, codecover should open up a wizard/popup and inform the user, that this project is not yet enabled for codecover. It should offer the user the option to enable it, together with the possible measurements available - just like in the current dialog under properties. I think this should enable a vast majority of users to advantage of codecover, without reading the start-up manual.

Annotation-based filtering support

2009-07-03T12:27:19Z

It would be prerty cool to have the possibility to declare parts, which are not desired to be counted into CodeCover's coverage measurements, directly in the source code - and not in the tool. Here are some thoughts:

- the developer should be able to add a @DontMeasureCoverage annotation in the class or method. CodeCover could also allow to specify which measures to skip, but an All-Or-Nothing approach would be perfect for the beginning.
- codecover automatically turns on filtering for this class or method and displays the coverage as "skipped" in the coverage summary and also in the detailed reports.
- this functionality should be configurable in codecover, so that CodeCover could also ignore those annoatations completely and process the code like it is doing that now (as of Version 1.001).

This would make testing of code with large amounts of deprecated methods, auto-generated parts etc. much more pleasant.

TestNG Support

2009-06-29T21:25:03Z

It would be pretty nice to have support for TestNG as well, not only JUnit 3/4.

Thread safety instrumentation

2008-01-16T17:23:45Z

Make the java instrumentation tread safety and allow the user to choose which instrumentation to make by setting an instrumentation directive.

Maven Support

2008-01-11T06:09:12Z

It would be great if this tool had a Maven plugin

Default package automattically added

2007-12-18T09:35:48Z

When first choosing the project property "codecover", the default package will not automatically be added to the codecover build path. The default package must be added manually (right click on the default package and select "Use for coverage measurement").

Metrics should do better caching.

2007-12-12T18:16:42Z

The current implementation is rather limited, it would be nice to perform more
extensive caching, probably in-memory only. This would give a big speed
increase when navigating the Coverage View (at the moment after every change a
full computation of the metrics occurs, causing major slowdowns for large
TSCs).