[ cobertura-Feature Requests-1443252 ] Mark untestable code

[SourceForge.net <no...@so...>]

Feature Requests item #1443252, was opened at 2006-03-04 18:02
Message generated for change (Comment added) made by jalbert631
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1443252&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jalbert (jalbert631)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mark untestable code

Initial Comment:
I would like to be able to mark small pieces of
"untestable" code (e.g. "catch" clauses for exceptions
that cannot be readily simulated), and have it marked
differently in the reports.

I would like to be able to mark code in some way. I
would suggest a comment flag at the start of each line
- say "/*--*/" (probably it should be configurable). If
a piece of unexecuted code is marked, it would be
flagged in the source listings in yellow, rather than
red, and the summary reports would show the percentage
of "untestable" code in yellow, in addition to the
current red and green bars.

The reason is that I cannot readily tell, when looking
at the reports, whether a lower-than-wanted percentage
of testing is because there is code that should be
tested but isn't, or code that cannot be tested. At
present, I can't tell it a few lines have been added
without testing, or it is still just the
knowingly-untested code that is being reported. If, in
a report, the green and yellow add up  to 100%, I know
there is no accidentally untested code.

The marks I am suggesting would look a little ugly, but
as far as I am concerned, that is fine - it  is nothing
something to be encouraged. This idea could be extended
in many ways - e.g. mark "code I will test later", etc.
- but I don't seen any need to get carried away.

----------------------------------------------------------------------

>Comment By: jalbert (jalbert631)
Date: 2007-09-12 08:51

Message:
Logged In: YES 
user_id=1467776
Originator: YES

The problem is that there are pieces of code that are difficult or
impossible to test in unit test. A typical example, as I mentioned in my
original post, is the catch clause for an exception that cannot easily be
simulated, such as a library that triggers an exception for a hardware
problem, or an invalid data condition that cannot be established.

Another example is code that is required but never intended to be
executed, such as a private constructor for a static class.

In some development methodologies, "trivial" methods, such as getters and
setters, are not required to be tested. Even though trivial, or generated
automatically by IDEs, they can form many lines of code in some classes,
and result in Cobertura reporting very low levels of coverage - low enough
that it is questionable whether the reports really have any value. (I do
not support this approach, and have written a JUnit extension to
automatically test most getters and setters, to eliminate this issue, but I
have worked in places where this was the case.)

----------------------------------------------------------------------

Comment By: Kasper B. Graversen (kbg)
Date: 2007-09-12 00:48

Message:
Logged In: YES 
user_id=118125
Originator: NO

Why are you not interested in testing your error handling code? or testing
that your units actually handless erroneous situations?

----------------------------------------------------------------------

Comment By: hasko (hasko)
Date: 2007-01-11 07:43

Message:
Logged In: YES 
user_id=99663
Originator: NO

It would also be nice to mark boilerplate code (e.g. toString) as not to
be tested. As an additional idea: the markup could be based on
annotations...

----------------------------------------------------------------------

Comment By: Bas Cancrinus (bascan)
Date: 2006-05-22 10:08

Message:
Logged In: YES 
user_id=437864

This would be a great solution to suppress coverage markers
on private constructors. They are usually used only to avoid
instantiation of utility classes, so they aren't covered by
definition.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1443252&group_id=130558