Specify Instrumented Classes/Packages/Working Set
Brought to you by:
mtnminds
In the Coverage... tab, you have the ability to only
select ALL source folders, or none at all.
I would like to run coverage on X tests, for which I am
only concerned with coverage on a specify working set -
or even package.
Since there are 8,000 classes, and I'm interested in
coverage on 500 of them, being able to set at Working
Set or package level what classes to instrument would
make using this plugin much faster
Thanks!
Logged In: YES
user_id=1586594
Thanks for your feedback! I already planed to replace the
flat list by a tree structure (srcfolder -> package ->
class). Using working sets on root level is a very good
idea. Stay tunded.
Logged In: YES
user_id=1586594
Originator: NO
Also consider adding pattern support (wildcard/regex).
Logged In: NO
I'd like to see this feature have a higher priority, I am working on a project with tens of thousands of class files, so the coverage analysis takes a very long time, even though I am only interested in a handful of classes.
Logged In: YES
user_id=1586594
Originator: NO
If you specify different output folders for your source folders, you can select source folders individually. For details check this forum thread:
https://sourceforge.net/forum/forum.php?thread_id=1620375&forum_id=614870
Logged In: YES
user_id=1654250
Originator: NO
Hi
It would be nice to have some defaults regarding output folders.
When i run a testcase under coverageAs for the first time
it selects by defaults all source to bin folders.
That way by default it includes into coverage also test classes.
(Output folders are different for each src tree)
Is that feasible?
Thankyou
Logged In: YES
user_id=1586594
Originator: NO
Any ideas where to specify these "defaults"? Should that be a global preference? Something that is project specific?
BTW: The speed of Coverage analysis has been increased by a factor of 50-100 with version 0.1.8; maybe selecting instrumented classes is not that important any more.
Logged In: YES
user_id=1654250
Originator: NO
Hi,
well it would be nice if we could set it via project preferences.
My src code is divided into two main trees.
src/java
src/unit
src/functional
i think i will never test coverage on my unit test but i will always test coverage on my src/java classes.
It makes no sense to see green lines on my testcase (maybe for some one it would make sense but it would be customizable via pref).
or to coverage all unit and functional trees since only src/java is under judgment.
By now i use to deselect manually each time i run a new testcase.
What do u think about?
Thank you.
ps: yes i feel the speed (0.1.8)!
Logged In: YES
user_id=1037926
Originator: NO
Count me in on a vote for this, too. I generally sort the data by package, and dislike the 'false positives' of the packages that are actually test packages. I'm also in a src/java src/test sort of environment (though I'm technically operating on 5 folders).
Logged In: YES
user_id=1586594
Originator: NO
Note that differnt source folders can be selected separately if they have different output locations, see http://www.eclemma.org/faq.html#usage02
Logged In: YES
user_id=1724347
Originator: NO
As a start, if I could simply turn off the display of all those classes that had absolutely no coverage, that'd give me an option to get a basic kind of filtering that would work for many simple cases. It's not ideal, because there may be a class in my intended coverage area that has no coverage, and I'd like to know that, but it'd be a start.
Fundamentally, it would be nice if this affected what was instrumented, instead of what was reported, but I'd settle, for now, to be able to filter the reported results.
Logged In: NO
I need select to instrument the classes that I am interested in and look forward to that you can add this function, thanks!
I posted a proposal to implement your feature request:
https://sourceforge.net/forum/forum.php?thread_id=2891281&forum_id=614869
Please feel free to add your comments!
-marc
The request was created on Oct, 2006 and now is Jan 2011.
More than 4 years for implementing. Is that not much?