Name: kbR10066 Date: 03/11/2002


Currently Jcov tools (report generator, data file merger) provide jcov data filtering
only at class level (-include -exclude options). But sometimes it is not enough, and
method/block/branch filtering is necessary. For example, java programs may have code
(methods/blocks/branches) which is executed only in some marginal cases
(internal error handling, code for debugging purposes, etc.), and it is hard or impossible
to perform a test which would cover such code pieces. Later, when report is generated,
these code pieces will decrease overall coverage percentage. And to find out why the
coverage is less than expected, a user has to browse through the marked-up source code
to make sure that the uncovered code is that "marginal" code and it is OK that it's not
covered.

Below is one more justification for this rfe (by Charles Brunson, <###@###.###>)

> One thing I've always
> wished for in a coverage tool
. . .
> is the ability to somehow specify methods/blocks/branches that I *don't*
> want to see coverage info for. Here's a use case for why I'd want this:
>
> Dev A writes code and a test to go with it. He instruments the code
> and runs the test. He analyzes the coverage data and makes decisions
> about uncovered code. In some cases he decides that he needs to add
> a test case and does so. In some cases though he decides that the
> unexecuted code is defensive in nature and that it would be either
> impossible or an inefficient use of his time.
>
>
> Sometime later Dev A leaves the company and Dev B takes over that
> code. He runs coverage against it and now he has to go thru the
> same analysis process that Dev A went thru (assuming there's still
> some uncoverfed code that Dev A decided not to write test cases
> for, for valid reasons).
>
> It would be nice if somehow Dev A could document those unexecuted
> areas and his reasons for leaving them uncovered in order to save
> Dev B some time/effort.
>
> Possible solutions:
> 1) One way would be for Dev A to just put comments in the code. Dev
> B would see those when he looked at the annotated source and know
> that someone else had already made a decision.
>
> 2) It would be cool if somehow one could tell the code coverage
> tool to ignore those areas in the future.
>
> Of course I can see problems with #2, where would you store that
> info? How would it stay in sync with the code? Where would you
> store the reasons why it was left uncovered so the next person
> could decide if they're still valid or not?

======================================================================