[ cobertura-Patches-2035169 ] Exclude methods from instrumentation (two for one sale)

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

Patches item #2035169, was opened at 2008-08-01 11:52
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720017&aid=2035169&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: Accepted
Priority: 5
Private: No
Submitted By: Scott Frederick (scottyfred)
Assigned to: John Lewis (lewijw)
Summary: Exclude methods from instrumentation (two for one sale)

Initial Comment:
This patch is a merge of two previous patches: 1576631 and 2009489. Patch 1576631 needed to be migrated from Cobertura 1.8 to 1.9, and there was significant overlap in the implementation of these two patches, so I merged them into one.

There are a few use cases for ignoring entire methods when generating coverage metrics. One is to ignore getters and setters that follow the JavaBean pattern.  There is usually little value in testing these methods, as their implementation is trivial and reliable. Another use case is to ignore code that is generated by another tool or technology during the build process.  There are other use cases as well. 

These two patches are meant to address use cases like these.

*** Ignore named methods ***

Patch 2009489 implemented a new optional parameter to specify the names of methods which should be excluded from instrumentation. 

The optional parameter "ignoreMethod", which can be used from command line or ant tasks, excludes entire methods from instrumentation. 

For method name matching, the specified ignore statement can be any substring of the actual method -- making the ignore method more powerful (e.g. ".set*" and ".get*" to ignore all setters and getters).

*** Ignore trivial methods ***

Patch 1576631 implemented a new optional parameter that enables the inspection of methods to identify those methods that follow the JavaBean pattern for getters and setters, and excludes those methods from instrumentation.

The Ant task and command-line Main accept a new boolean option named "ignoreTrivial". If this option is set to "true", methods that match the criteria below are excluded from coverage. If the option is set to "false", all methods are included as Cobertura does today.

The criteria for deciding a method is trivial are:

getters:
- method name begins with "get", "is", or "has"
- method accepts no arguments
- method return type is non-void
- method contains only bytecode instructions for getting member field values

setters:
- method name begins with "set"
- method accepts exactly one argument
- method return type is void
- method contains only bytecode instructions for setting member field values

initializers:
- method name is "<init>" (constructors and implicit initializers)
- method contains only bytecode instructions for setting member field values and calling initializer method of immediate superclass (e.g. "super();")

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

Comment By: Nobody/Anonymous (nobody)
Date: 2013-04-04 18:16

Message:
Les entreprises n'ont pas été en mesure de rivaliser sur les prix et que
vous essayez d'utiliser les fonctionnalités de rivaliser au lieu et au
cours des six derniers mois seulement, nous avons vu le téléphone
portable à énergie solaire, de la télévision mobile téléphone et
montre sortir de Chine avant, il est apparu nulle part ailleurs avec de
nombreuses marques plus grandes même pas libérer une montre téléphone
cellulaire. foakleys hijinx
http://www.pascheroakleys.net/oakley-hijinx-c-33.html

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

Comment By: Nobody/Anonymous (nobody)
Date: 2013-04-04 09:17

Message:
Unlike in the past, wearing prescription eyeglasses is no longer something
to shameful of and boys DO make passes at girls who wear glasses! While
you'll always be able to find cheap eyeglasses online, it's better to find
a high quality pair of eye glasses than to buy something just because it's
the cheaper option. Today's glasses aren't made with the same quality
materials as they used to be because people aren't wearing the same pair of
eyeglasses for as long as they used to. While the industry has evolved, so
have the people wearing eyeglasses. foakleys
http://fakeoakleysport-soaho.webs.com

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

Comment By: John Lewis (lewijw)
Date: 2010-07-07 18:16

Message:
Part of this patch has been applied.   Please see:

https://sourceforge.net/tracker/index.php?func=detail&aid=3010530&group_id=130558&atid=720017

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-10 11:19

Message:
There are lots of suggested ways to control what is measured for coverage.
To reiterate my requirements and motivation for this patch: 

- I do NOT want to specify a method name pattern for exclusion/ignoring.
This leaves me open to ignoring methods that look like getters/setters but
in fact are not trivial and should be tested. 
- I do NOT wan to annotate, otherwise decorate, or provide a list of all
methods to exclude/ignore. It would be a lot of work to manually identify
all the candidate methods and it would become a maintenance headache. 
- I DO want the tool to automatically identify methods that are truly
trivial, using a very tight and conservative set of heuristics (as detailed
in the patch description). 

In other words, in the case of trivial getters and setters I don't care to
have complete control over what is excluded, I want the tool to help me out
and allow me to do less configuration work to get the desires outcome. 

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

Comment By: Ho Tri Bao (hotribao)
Date: 2008-12-09 08:33

Message:
Well, I totally agree with the point of scottyfred: "it is dangerous to
exclude getters and setters from coverage metrics based only on the name of
the method". But let me state it in a different way: "It is dangerous to
exclude methods from coverage metrics based on method name pattern. AND we
have no control on what were excluded"

But we have to agree that this is a real need.

I submitted a patch which solve these issues:
- Excluded methods (I called it ignored methods) can be enumerated,
wildcard is supported (I think using wildcard is simply enough for all
people)
- Excluded methods are reported (easy to realize) on source code view of a
class
- Risky Excluded methods are also reported: risky excluded methods are the
ones that are complex but were excluded

So, you are fully control what were excluded.

Since the feature uses complexity calculation. And there is a bug for this
in JDK 1.5+. This bug was also fixed in this patch.

There are more features included in that patch also, such as top project
risks (risky classes, risky methods)

The patch is here:
https://sourceforge.net/tracker/index.php?func=detail&aid=2353196&group_id=130558&atid=720017

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

Comment By: Scott Frederick (scottyfred)
Date: 2008-08-01 12:03

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

So, which new option to use? This has been debated in the descriptions and
comments of the related patches.

In my opinion, it is dangerous to exclude getters and setters from coverage
metrics based only on the name of the method. Methods that start with "get"
can contain calculations, and methods that start with "set" can have
side-effects beyond just setting the value of a single data member. These
"non-trivial" getters and setters (which probably violate the JavaBean
pattern) should be tested, and should not be excluded from coverage
metrics.  The "ignoreTrivial" enhancement in this patch goes beyond
inspecting just the method name, to inspect the method signature (to match
only methods that follow the JavaBean signature pattern) and the byte code
contained in the method (to match only methods that get or set the value of
a single data member as appropriate). 

If you have some other way (like static code checking) to enforce that
methods named with "get" and "set" follow a pattern, the excluding coverage
by name might work just file. Otherwise, I think "ignoreTrivial" comes a
lot closer to what you want for this use case than simple name matching
does. This was the original thinking behind patch 1576631.

That's just my opinion; your team and your project are almost certainly
different than mine. Two options are provided here, other patches have been
submitted to support annotation-based exclusion. Use whichever method works
for you.

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

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