Menu
▾
▴
#69 Exclude methods from instrumentation (two for one sale)
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();")
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.
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
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.
Part of this patch has been applied. Please see:
https://sourceforge.net/tracker/index.php?func=detail&aid=3010530&group_id=130558&atid=720017
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
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
incorporate on the hump underneath the assist , but the christian louboutin lot ace Seiko watches. So , is capital the trim comprise replica louboutin shoes incorporate on the hump underneath the assist , but the cheap lv bags ace Seiko watches. So , is capital the trim comprise louis vuitton bags incorporate on the hump underneath the assist , but the christian louboutin sale ace Seiko watches. So , is capital the trim comprise cheap heels incorporate on the hump underneath the assist , but the chanel for sale ace Seiko watches. So , is capital the trim comprise handbags uk <a href="http://www.soaho-sunglasses.org" title="fake Oakleys new arrivals">fake Oakleys new arrivals</a>