Recent changes to feature-requests

Correlation

Matthew Ricks — Thu, 01 Nov 2012 23:24:18 -0000

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

vamshi dommeti — Fri, 11 Jun 2010 10:58:21 -0000

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

Daniel Kulesz — Thu, 28 Jan 2010 18:00:37 -0000

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

Daniel Kulesz — Fri, 03 Jul 2009 12:27:19 -0000

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

Daniel Kulesz — Mon, 29 Jun 2009 21:25:03 -0000

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

Thread safety instrumentation

Christoph Kreidler — Wed, 16 Jan 2008 17:23:45 -0000

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

Maven Support

Anonymous — Fri, 11 Jan 2008 06:09:12 -0000

It would be great if this tool had a Maven plugin

Default package automattically added

Anonymous — Tue, 18 Dec 2007 09:35:48 -0000

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.

Tilmann Scheller — Wed, 12 Dec 2007 18:16:42 -0000

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