#109 Filtering extension for method level instrumentation

[Ben2Lau]

Currently, EMMA instruments classes(both at runtime
and offline instrumentation)by packages and/classes.
It would be desirable to be able to extend additional
filtering at method level to have selectiev method
coverage:

The main use case is that certain methods are being
deprecated or whose coverage are already certain from
previous coverage runs.
So there's no need to do coverage on those methods.
Benefit:This will speed up coverage as well since
previous coverage can all be merged.

Suggest that filtering syntax might look like this:

1) Filter out methods "method1()", "method2()"
from class com.a.b.xyz.SomeClass1:

-com.a.b.xyz.SomeClass1#{method1, method2}

2)Filter in methods that start with "getResource..."
from class com.a.b.xyz.SomeClass1:

+com.a.b.xyz.SomeClass1#{getResource*}

3)Filter out overloaded methods that start
with "getProperty" that have argument (int, String)
and (int, int, Object)
from class com.a.b.xyz.SomeClass1

-com.a.b.xyz.SomeClass1#{getProperty
(int,java.lang.String),(int,int,java.lang.Object)}

[Daniel Deveaux]

Logged In: YES
user_id=774874
Originator: NO

Hello,
I have an other good reason to support this request.
I am now integrating the EMMA code coverage tool in my STclass "Contract Based Built-in Test" Framework (see http://stclass.org/\).
In this built-n testing approach, the test-cases are implemented as methods in the Class Under Test (CUT) itself. If the tests pass, a part of this testing methods is never visited, but this no covered code is not significant for the final class.
The methods that should be filtered in this case have standard prefixes ("TC_", "TS_", "__" and the generated "main") and the above proposed syntax is fine for me.
If the answer to this request is not too heavy, our team can work on this request.

best regard

Daniel

[estaub_tel]

Logged In: YES
user_id=1651631
Originator: NO

Here's another "vote" for this feature.
In our case, we have a large body of code that doesn't have significant unit tests or coverage testing.
To make the workload palatable, introduction of unit tests must be incremental, focused initially in areas that are under modification.
Often the boundaries of the area for which tests should be developed in a given project do not follow class boundaries.

[Leo J. Hart IV]

I also vote for this feature. I am currently a user of Clover, which allows you to filter on package, class, method and statements (the latter two by using regex's). This is incredibly useful for filtering out code that a given team determines to be "safe": simple constructors and getter/setters.