[ cobertura-Feature Requests-2353057 ] Many in one: Ignoring certain methods from coverage calculat

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

Feature Requests item #2353057, was opened at 2008-11-27 15:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2353057&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: Ho Tri Bao (hotribao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many in one: Ignoring certain methods from coverage calculat

Initial Comment:
Cobertura is great. However, we are looking forward for the integration of these features to the future release of Cobertura. They are very useful feature for us. When going through the list of feature requests and patches, I found similar ideas. But they are separate while we need all of them. Hence I develop a patch which contains all of them and I would like to contribute them here:


==================================
1. Bug fix for zero-complexity bug
   - Cobertura usually reports zero-complexity for source codes written in Java5 (due to new syntaxes)
   - Cobertura reports the complexity as average value (e.g. total complexity of the class divides by number of methods in the class). This could give a false sense: A class with one complex method and many getters/setters can become a simple class. So, the accumulated complexity should be shown instead (although it can give a false sense also! But at least more reasonable, a class with many simple methods can become complex)
   
   This should be put in the "Bugs" section. However, I would like to mention it here since the result of fixing this bug will be used in the following features.
   This can be same as the problem reported here http://sourceforge.net/tracker/index.php?func=detail&aid=2207940&group_id=130558&atid=720015

==================================
2. Ignoring certain methods from coverage calculation
   Currently, all methods in a class are taken into account when calculating the coverage rate. However, in pragmatic testing, there are trivial methods that we never test. We should be able to exclude these methods from calculating the coverage rate.
   There are 3 things:
     - It should be possible to specify which methods in which classes that will be ignored. Notice the case of overloading methods
     - Information about ignored methods (which methods are ignored) should be shown in the HTML report
     - The HTML report should also shown the list of ignored methods order by their complexity. This is to prevent mistaking when declaring ignored methods (since regular expression/wildcards can be used). This is also used to check that if some people in a team intentionally ignored complex methods that they should test :-)

   This can be same as the requested feature: http://sourceforge.net/tracker/index.php?func=detail&aid=1172106&group_id=130558&atid=720018

==================================
3. Listing risky classes/methods
   Showing how many percentages of codes are covered by test is very good. But not enough in pragmatic test: it should also show which classes, which methods that require more tests. Bugs normally come from complex methods. Hence if a class/method is complex but does not have high coverage rate (line coverage is enough), one should consider testing it.
   
   This is something like what is done by Clover: http://www.atlassian.com/software/clover/features/hotspots.jsp
   This is also similar to the features requested here: http://sourceforge.net/tracker/index.php?func=detail&aid=1439558&group_id=130558&atid=720018 and here http://sourceforge.net/tracker/index.php?func=detail&aid=1182501&group_id=130558&atid=720018
   

==================================
4. On-the-fly instrumentation
   Currently, Cobertura only work in offline mode. Meaning all classes must be instrumented before being run. This leads to some limitations:
   - Lose time when developing unit test: imagine a developer is writing unit test for one class in a big project with Maven for example. Then in order to get the coverage report he has to type mvn cobertura:cobertura which will provoke the compilation process. Just to get coverage report of one class, he has to compile the whole project. And normally, many things happen at the compilation time: jsp compile, checkstyle check, pmd check... So, it's time waste.
     The ideal case is that: the developer just runs the unit test within Eclipse then he gets the coverage report for the class that he tests.
     
   - Cobertura can be used not only for unit test coverage but also for other tests (FAT, for example). That could be a risk (and it's not good) that we deliver the instrumented EAR/WAR to our customer. The ideal case is that the class will be instrumented when it is loaded at the first time.
   
   It's similar to the requested feature here: http://sourceforge.net/tracker/index.php?func=detail&aid=1483233&group_id=130558&atid=720018

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

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