Menu
▾
▴
cobertura-devel — General questions about using and developing Cobertura.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(66) |
Apr
(29) |
May
(85) |
Jun
(66) |
Jul
(24) |
Aug
(139) |
Sep
(72) |
Oct
(26) |
Nov
(142) |
Dec
(34) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(55) |
Feb
(72) |
Mar
(43) |
Apr
(60) |
May
(95) |
Jun
(22) |
Jul
(48) |
Aug
(17) |
Sep
(54) |
Oct
(30) |
Nov
(82) |
Dec
(17) |
| 2007 |
Jan
(23) |
Feb
(38) |
Mar
(46) |
Apr
(12) |
May
(77) |
Jun
(77) |
Jul
(94) |
Aug
(51) |
Sep
(38) |
Oct
(57) |
Nov
(39) |
Dec
(67) |
| 2008 |
Jan
(38) |
Feb
(56) |
Mar
(42) |
Apr
(46) |
May
(37) |
Jun
(43) |
Jul
(52) |
Aug
(22) |
Sep
(22) |
Oct
(34) |
Nov
(37) |
Dec
(29) |
| 2009 |
Jan
(27) |
Feb
(35) |
Mar
(67) |
Apr
(37) |
May
(31) |
Jun
(79) |
Jul
(71) |
Aug
(59) |
Sep
(31) |
Oct
(47) |
Nov
(36) |
Dec
(7) |
| 2010 |
Jan
(15) |
Feb
(87) |
Mar
(38) |
Apr
(33) |
May
(24) |
Jun
(47) |
Jul
(26) |
Aug
(28) |
Sep
(33) |
Oct
(13) |
Nov
(8) |
Dec
(36) |
| 2011 |
Jan
(32) |
Feb
(10) |
Mar
(29) |
Apr
(29) |
May
(17) |
Jun
(14) |
Jul
(33) |
Aug
(11) |
Sep
(7) |
Oct
(7) |
Nov
(6) |
Dec
(10) |
| 2012 |
Jan
(19) |
Feb
(12) |
Mar
(16) |
Apr
(6) |
May
(18) |
Jun
(18) |
Jul
(31) |
Aug
(25) |
Sep
|
Oct
(31) |
Nov
(21) |
Dec
(9) |
| 2013 |
Jan
(8) |
Feb
(16) |
Mar
(8) |
Apr
(7) |
May
(3) |
Jun
(29) |
Jul
(29) |
Aug
|
Sep
(7) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2014 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(13) |
May
(8) |
Jun
(5) |
Jul
(2) |
Aug
(4) |
Sep
(4) |
Oct
(2) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Xuesong C. <xue...@ms...> - 2010-06-03 15:15:58
|
Hi There, In my project I need to use a library called classmexer (http://www.javamex.com/classmexer/) to measure memory usage of a java object. But it seems it conflicts with cobertura (unit tests are fine without using cobertura but broken with cobertura) Based on my investigation, it seems it is due to the fact that both classmexer and cobertura use Java Instrumentation framework. Anybody met this problem before? Any solution? Thanks! Arthur _________________________________________________________________ http://clk.atdmt.com/UKM/go/195013117/direct/01/ |
|
From: Soni, A. IN B. S. <ash...@si...> - 2010-06-03 06:44:42
|
But if I want to exclude some file and folder with specific name then I have to include them in excludeClasses?
Like:
<excludeClasses regex="*.*Test*" />
<excludeClasses regex="*.contrib.*" />
<excludeClasses regex="*.ImsMessageIds*" />
<excludeClasses regex="*Mock*" />
<excludeClasses regex="PackageTestSuite*" />
<excludeClasses regex="*Base64*" />
<excludeClasses regex="*TransformerUI*" />
But when I am using this I am getting the error like:
[cobertura-instrument] WARN addRegex, The regular expression *.*Test* is invalid: ?+* follows nothing in expression
[cobertura-instrument] WARN addRegex, The regular expression *.contrib.* is invalid: ?+* follows nothing in expression
[cobertura-instrument] WARN addRegex, The regular expression *.ImsMessageIds is invalid: ?+* follows nothing in expression
[cobertura-instrument] WARN addRegex, The regular expression *Mock* is invalid: ?+* follows nothing in expression
[cobertura-instrument] WARN addRegex, The regular expression *Base64* is invalid: ?+* follows nothing in expression
[cobertura-instrument] WARN addRegex, The regular expression *TransformerUI* is invalid: ?+* follows nothing in expression
Same rule is working fine in Emma Code coverage.
----------------------------------------------------------------
With best regards,
Ashish Soni
Siemens Information Systems Ltd.
SWP-HC3
No 84, Keonics Electronics City,
Hosur Road, Bangalore 560100
Tel.: +91 80 2511 3353
mailto.: ash...@si...<mailto:ash...@si...>
www.siemens.co.in<BLOCKED::http://www.siemens.co.in>
________________________________
From: John W. Lewis [mailto:Joh...@sa...]
Sent: Thursday, June 03, 2010 1:20 AM
To: Soni, Ashish IN BLR SISL; cob...@li...
Subject: RE: Uses of Cobertura-instrument task
You will probably want to use something more like (from http://cobertura.sourceforge.net/anttaskreference.html):
<cobertura-instrument todir="${instrumented.dir}">
<includeClasses regex=".*" />
<excludeClasses regex=".*\.Test.*" />
<instrumentationClasspath>
<path refid="test.classpath" />
<pathelement location="${test.build}" />
</instrumentationClasspath>
</cobertura-instrument>
The regular expressions would be ".*Test.*", ".*\.contrib\..*", etc.
John
From: Soni, Ashish IN BLR SISL [mailto:ash...@si...]
Sent: Wednesday, June 02, 2010 4:47 AM
To: cob...@li...
Cc: Soni, Ashish IN BLR SISL
Subject: [Cobertura-devel] Uses of Cobertura-instrument task
Hello All,
Can please help me for following scenario:
I want to do the Cobertura instrumentation on more than 1 jar and one gen\classes folder but I want to do for some specific package.
Like:
<!--include/exclude package pattern set -->
<patternset id="filter.instrument">
<include name="org/jaxen/javabean/${package.name}/*"/>
<exclude name="*/*Test*" />
<exclude name="*/contrib.*" />
<exclude name="*/ImsMessageIds" />
<exclude name="*Mock*" />
<exclude name="PackageTestSuite*" />
<exclude name="*Base64*" />
<exclude name="*TransformerUI*" />
</patternset>
<cobertura-instrument todir="${dir.build}/cobertura.ser">
<fileset dir="${ dir.build.jars}">
<include name="A1.jar" />
<include name="A2.jar" />
<include name="A3.jar" />
<include name="A4.jar" />
<include name="A5.jar" />
<include name="A6.jar" />
<include name="A7.jar" />
<include name="A8.jar" />
<patternset refid="filter.instrument"/>
</fileset>
<fileset dir="${dir.build.class}">
<include name="org/jaxen/javabean/${package.name}/*"/>
<exclude name="*/*Test*" />
<exclude name="*/contrib.*" />
<exclude name="*/ImsMessageIds" />
<exclude name="*Mock*" />
<exclude name="PackageTestSuite*" />
<exclude name="*Base64*" />
<exclude name="*TransformerUI*" />
<patternset refid="filter.instrument"/>
</fileset>
</cobertura-instrument>
Please help me for the above example is that will work or I have to write it in different way.
In Advance Thanks for the help.
----------------------------------------------------------------
With best regards,
Ashish Soni
Siemens Information Systems Ltd.
SWP-HC3
No 84, Keonics Electronics City,
Hosur Road, Bangalore 560100
Tel.: +91 80 2511 3353
mailto.: ash...@si...<mailto:ash...@si...>
www.siemens.co.in<BLOCKED::http://www.siemens.co.in>
________________________________
Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system.
Thank You.
________________________________
Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system.
Thank You.
|
|
From: John W. L. <Joh...@sa...> - 2010-06-02 19:50:12
|
You will probably want to use something more like (from http://cobertura.sourceforge.net/anttaskreference.html): <cobertura-instrument todir="${instrumented.dir}"> <includeClasses regex=".*" /> <excludeClasses regex=".*\.Test.*" /> <instrumentationClasspath> <path refid="test.classpath" /> <pathelement location="${test.build}" /> </instrumentationClasspath> </cobertura-instrument> The regular expressions would be ".*Test.*", ".*\.contrib\..*", etc. John From: Soni, Ashish IN BLR SISL [mailto:ash...@si...] Sent: Wednesday, June 02, 2010 4:47 AM To: cob...@li... Cc: Soni, Ashish IN BLR SISL Subject: [Cobertura-devel] Uses of Cobertura-instrument task Hello All, Can please help me for following scenario: I want to do the Cobertura instrumentation on more than 1 jar and one gen\classes folder but I want to do for some specific package. Like: <!--include/exclude package pattern set --> <patternset id="filter.instrument"> <include name="org/jaxen/javabean/${package.name}/*"/> <exclude name="*/*Test*" /> <exclude name="*/contrib.*" /> <exclude name="*/ImsMessageIds" /> <exclude name="*Mock*" /> <exclude name="PackageTestSuite*" /> <exclude name="*Base64*" /> <exclude name="*TransformerUI*" /> </patternset> <cobertura-instrument todir="${dir.build}/cobertura.ser"> <fileset dir="${ dir.build.jars}"> <include name="A1.jar" /> <include name="A2.jar" /> <include name="A3.jar" /> <include name="A4.jar" /> <include name="A5.jar" /> <include name="A6.jar" /> <include name="A7.jar" /> <include name="A8.jar" /> <patternset refid="filter.instrument"/> </fileset> <fileset dir="${dir.build.class}"> <include name="org/jaxen/javabean/${package.name}/*"/> <exclude name="*/*Test*" /> <exclude name="*/contrib.*" /> <exclude name="*/ImsMessageIds" /> <exclude name="*Mock*" /> <exclude name="PackageTestSuite*" /> <exclude name="*Base64*" /> <exclude name="*TransformerUI*" /> <patternset refid="filter.instrument"/> </fileset> </cobertura-instrument> Please help me for the above example is that will work or I have to write it in different way. In Advance Thanks for the help. ---------------------------------------------------------------- With best regards, Ashish Soni Siemens Information Systems Ltd. SWP-HC3 No 84, Keonics Electronics City, Hosur Road, Bangalore 560100 Tel.: +91 80 2511 3353 mailto.: ash...@si...<mailto:ash...@si...> www.siemens.co.in<BLOCKED::http://www.siemens.co.in> ________________________________ Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank You. |
|
From: John W. L. <Joh...@sa...> - 2010-06-02 19:46:32
|
The todir in cobertura-instrument should be a directory. You have "${dir.build}/cobertura.ser".
John
From: Soni, Ashish IN BLR SISL [mailto:ash...@si...]
Sent: Wednesday, June 02, 2010 4:47 AM
To: cob...@li...
Cc: Soni, Ashish IN BLR SISL
Subject: [Cobertura-devel] Uses of Cobertura-instrument task
Hello All,
Can please help me for following scenario:
I want to do the Cobertura instrumentation on more than 1 jar and one gen\classes folder but I want to do for some specific package.
Like:
<!--include/exclude package pattern set -->
<patternset id="filter.instrument">
<include name="org/jaxen/javabean/${package.name}/*"/>
<exclude name="*/*Test*" />
<exclude name="*/contrib.*" />
<exclude name="*/ImsMessageIds" />
<exclude name="*Mock*" />
<exclude name="PackageTestSuite*" />
<exclude name="*Base64*" />
<exclude name="*TransformerUI*" />
</patternset>
<cobertura-instrument todir="${dir.build}/cobertura.ser">
<fileset dir="${ dir.build.jars}">
<include name="A1.jar" />
<include name="A2.jar" />
<include name="A3.jar" />
<include name="A4.jar" />
<include name="A5.jar" />
<include name="A6.jar" />
<include name="A7.jar" />
<include name="A8.jar" />
<patternset refid="filter.instrument"/>
</fileset>
<fileset dir="${dir.build.class}">
<include name="org/jaxen/javabean/${package.name}/*"/>
<exclude name="*/*Test*" />
<exclude name="*/contrib.*" />
<exclude name="*/ImsMessageIds" />
<exclude name="*Mock*" />
<exclude name="PackageTestSuite*" />
<exclude name="*Base64*" />
<exclude name="*TransformerUI*" />
<patternset refid="filter.instrument"/>
</fileset>
</cobertura-instrument>
Please help me for the above example is that will work or I have to write it in different way.
In Advance Thanks for the help.
----------------------------------------------------------------
With best regards,
Ashish Soni
Siemens Information Systems Ltd.
SWP-HC3
No 84, Keonics Electronics City,
Hosur Road, Bangalore 560100
Tel.: +91 80 2511 3353
mailto.: ash...@si...<mailto:ash...@si...>
www.siemens.co.in<BLOCKED::http://www.siemens.co.in>
________________________________
Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system.
Thank You.
|
|
From: Tad S. <ts...@lw...> - 2010-06-02 15:19:26
|
I've uploaded my patch here: https://sourceforge.net/tracker/?func=detail&aid=3010530&group_id=130558&atid=720017 I've uploaded two versions of my patch. A normal diff patch output and a zip file that contains all changed files (and one new file). You can use whatever form is more convenient for you. Thanks, -- Tad |
|
From: John W. L. <Joh...@sa...> - 2010-06-02 12:32:30
|
It sounds like these are good improvements. Please submit the patch and I'll apply it. Thanks! -----Original Message----- From: Afonso Araújo Neto [mailto:afo...@gm...] Sent: Wednesday, June 02, 2010 5:55 AM To: cob...@li..." Subject: Re: [Cobertura-devel] Excluding Methods from coverage report I think those are excellent additions to Cobertura. If it's just a patch to add to the source, it appears to be very easy to include them without bothering the developers too much. I'm really looking forward to see these features in an official release. Regards, Afonso Araújo Neto On Tue, Jun 1, 2010 at 6:56 PM, Tad Smith <ts...@lw...> wrote: > Correct. --ignoreTrivial should never exclude the equals, hashCode, or toString methods. I put my project's custom annotation on all generated equals, hashCode, and toString methods. That gets me the rest of the way there. If you wish to run the build without ignoring these methods, then don't include the --ignoreMethodAnnotations flag. It's very flexible, so it can be used for projects with a variety of requirements. > > Thanks, > -- Tad > > > From: Bennett, Jeffrey [mailto:JJB...@On...] > Sent: Tuesday, June 01, 2010 11:50 AM > To: Tad Smith; cob...@li... > Subject: RE: [Cobertura-devel] Excluding Methods from coverage report > > Speaking only for myself, I'd hate --ignoreTrivial (but I can simply choose not to use it). > 1.) I frequently find myself looking at coverage reports to find dead-code. Often, the dead code is in these simple methods so I'd hate to lose this capability. > 2.) It sounds like equals, hashCode and toString will never be excluded by ignoreTrivial, so this solution only gets you part way to your goal (albeit, perhaps a big step) > > The ignoreMethodAnnotations looks intriguing. Does that mean that by adding an annotation to a method, you can make cobertura ignore any arbitrary method? That would be fantastic. > > ________________________________________ > From: Tad Smith [mailto:ts...@lw...] > Sent: Tuesday, June 01, 2010 11:30 AM > To: cob...@li... > Subject: [Cobertura-devel] Excluding Methods from coverage report > There seems to be a real need to be able to exclude certain methods from the coverage report and multiple patch to do so have been submitted over the years, but none seem to have been included in the baseline. > > On my project we use Eclipse to generate getters/setters, hashCode(), equals(), and toString() methods. This is a real timesaver. Since these methods are generated, we have no desire to ensure that they are unit tested via JUnit. However, they are currently showing up in our Cobertura coverage report. The affect of this is that they are adding "noise" to the report. When these generated methods do not show up in the coverage report, it's easier to see what code, which was actually written by a developer, needs additional JUnit tests. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) > > I have taken this patch: > https://sourceforge.net/tracker/?func=detail&aid=2035169&group_id=130558&atid=720017 > and merged it into the 1.9.4.1 baseline. This patch provides the "--ignoreTrivial" flag. This analyzes the bytes code of the method and determines if it is a simple getter/setter method or constructor and if so, it is excluded from the coverage report. If it has additional logic in the method, then it is not ignored. In addition, the flag has to be set to enable this functionality. This should be a pretty safe change. This patch also contains a "--ignoreMethod" which is a list of regular expressions of method names to ignore. I don't really agree with this approach so this has been removed from my patch merge. > > I have also added a new flag "--ignoreMethodAnnotations" which takes a list of annotation class names. (i.e. com.lwlmco.ross.server.util.IgnoreInCoverageReport) If one of the annotations specified by this list is found on a method, then it will be ignored in the coverage report. This allows a project to use whatever annotation they desire to ignore methods in the coverage report. Developers are forced to consciously specify a method that should not show up in the coverage report (and this should be caught in code reviews). Again, if this flag is not set, it will not modify current behavior, so it's a safe change to make. > > I would like to get this into the project baseline and would like to know what is required to do so. > > Thanks, > -- Tad > > ------------------------------------------------------------------------------ > > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > ------------------------------------------------------------------------------ _______________________________________________ Cobertura-devel mailing list Cob...@li... https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
|
From: Afonso A. N. <afo...@gm...> - 2010-06-02 09:55:19
|
I think those are excellent additions to Cobertura. If it's just a patch to add to the source, it appears to be very easy to include them without bothering the developers too much. I'm really looking forward to see these features in an official release. Regards, Afonso Araújo Neto On Tue, Jun 1, 2010 at 6:56 PM, Tad Smith <ts...@lw...> wrote: > Correct. --ignoreTrivial should never exclude the equals, hashCode, or toString methods. I put my project's custom annotation on all generated equals, hashCode, and toString methods. That gets me the rest of the way there. If you wish to run the build without ignoring these methods, then don't include the --ignoreMethodAnnotations flag. It's very flexible, so it can be used for projects with a variety of requirements. > > Thanks, > -- Tad > > > From: Bennett, Jeffrey [mailto:JJB...@On...] > Sent: Tuesday, June 01, 2010 11:50 AM > To: Tad Smith; cob...@li... > Subject: RE: [Cobertura-devel] Excluding Methods from coverage report > > Speaking only for myself, I'd hate --ignoreTrivial (but I can simply choose not to use it). > 1.) I frequently find myself looking at coverage reports to find dead-code. Often, the dead code is in these simple methods so I'd hate to lose this capability. > 2.) It sounds like equals, hashCode and toString will never be excluded by ignoreTrivial, so this solution only gets you part way to your goal (albeit, perhaps a big step) > > The ignoreMethodAnnotations looks intriguing. Does that mean that by adding an annotation to a method, you can make cobertura ignore any arbitrary method? That would be fantastic. > > ________________________________________ > From: Tad Smith [mailto:ts...@lw...] > Sent: Tuesday, June 01, 2010 11:30 AM > To: cob...@li... > Subject: [Cobertura-devel] Excluding Methods from coverage report > There seems to be a real need to be able to exclude certain methods from the coverage report and multiple patch to do so have been submitted over the years, but none seem to have been included in the baseline. > > On my project we use Eclipse to generate getters/setters, hashCode(), equals(), and toString() methods. This is a real timesaver. Since these methods are generated, we have no desire to ensure that they are unit tested via JUnit. However, they are currently showing up in our Cobertura coverage report. The affect of this is that they are adding "noise" to the report. When these generated methods do not show up in the coverage report, it's easier to see what code, which was actually written by a developer, needs additional JUnit tests. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) > > I have taken this patch: > https://sourceforge.net/tracker/?func=detail&aid=2035169&group_id=130558&atid=720017 > and merged it into the 1.9.4.1 baseline. This patch provides the "--ignoreTrivial" flag. This analyzes the bytes code of the method and determines if it is a simple getter/setter method or constructor and if so, it is excluded from the coverage report. If it has additional logic in the method, then it is not ignored. In addition, the flag has to be set to enable this functionality. This should be a pretty safe change. This patch also contains a "--ignoreMethod" which is a list of regular expressions of method names to ignore. I don't really agree with this approach so this has been removed from my patch merge. > > I have also added a new flag "--ignoreMethodAnnotations" which takes a list of annotation class names. (i.e. com.lwlmco.ross.server.util.IgnoreInCoverageReport) If one of the annotations specified by this list is found on a method, then it will be ignored in the coverage report. This allows a project to use whatever annotation they desire to ignore methods in the coverage report. Developers are forced to consciously specify a method that should not show up in the coverage report (and this should be caught in code reviews). Again, if this flag is not set, it will not modify current behavior, so it's a safe change to make. > > I would like to get this into the project baseline and would like to know what is required to do so. > > Thanks, > -- Tad > > ------------------------------------------------------------------------------ > > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > |
|
From: Soni, A. IN B. S. <ash...@si...> - 2010-06-02 09:22:31
|
Hello All,
Can please help me for following scenario:
I want to do the Cobertura instrumentation on more than 1 jar and one gen\classes folder but I want to do for some specific package.
Like:
<!--include/exclude package pattern set -->
<patternset id="filter.instrument">
<include name="org/jaxen/javabean/${package.name}/*"/>
<exclude name="*/*Test*" />
<exclude name="*/contrib.*" />
<exclude name="*/ImsMessageIds" />
<exclude name="*Mock*" />
<exclude name="PackageTestSuite*" />
<exclude name="*Base64*" />
<exclude name="*TransformerUI*" />
</patternset>
<cobertura-instrument todir="${dir.build}/cobertura.ser">
<fileset dir="${ dir.build.jars}">
<include name="A1.jar" />
<include name="A2.jar" />
<include name="A3.jar" />
<include name="A4.jar" />
<include name="A5.jar" />
<include name="A6.jar" />
<include name="A7.jar" />
<include name="A8.jar" />
<patternset refid="filter.instrument"/>
</fileset>
<fileset dir="${dir.build.class}">
<include name="org/jaxen/javabean/${package.name}/*"/>
<exclude name="*/*Test*" />
<exclude name="*/contrib.*" />
<exclude name="*/ImsMessageIds" />
<exclude name="*Mock*" />
<exclude name="PackageTestSuite*" />
<exclude name="*Base64*" />
<exclude name="*TransformerUI*" />
<patternset refid="filter.instrument"/>
</fileset>
</cobertura-instrument>
Please help me for the above example is that will work or I have to write it in different way.
In Advance Thanks for the help.
----------------------------------------------------------------
With best regards,
Ashish Soni
Siemens Information Systems Ltd.
SWP-HC3
No 84, Keonics Electronics City,
Hosur Road, Bangalore 560100
Tel.: +91 80 2511 3353
mailto.: ash...@si...<mailto:ash...@si...>
www.siemens.co.in<BLOCKED::http://www.siemens.co.in>
________________________________
Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system.
Thank You.
|
|
From: Bennett, J. <JJB...@On...> - 2010-06-01 18:16:02
|
Speaking only for myself, I'd hate --ignoreTrivial (but I can simply choose not to use it). 1.) I frequently find myself looking at coverage reports to find dead-code. Often, the dead code is in these simple methods so I'd hate to lose this capability. 2.) It sounds like equals, hashCode and toString will never be excluded by ignoreTrivial, so this solution only gets you part way to your goal (albeit, perhaps a big step) The ignoreMethodAnnotations looks intriguing. Does that mean that by adding an annotation to a method, you can make cobertura ignore any arbitrary method? That would be fantastic. ________________________________ From: Tad Smith [mailto:ts...@lw...] Sent: Tuesday, June 01, 2010 11:30 AM To: cob...@li... Subject: [Cobertura-devel] Excluding Methods from coverage report There seems to be a real need to be able to exclude certain methods from the coverage report and multiple patch to do so have been submitted over the years, but none seem to have been included in the baseline. On my project we use Eclipse to generate getters/setters, hashCode(), equals(), and toString() methods. This is a real timesaver. Since these methods are generated, we have no desire to ensure that they are unit tested via JUnit. However, they are currently showing up in our Cobertura coverage report. The affect of this is that they are adding "noise" to the report. When these generated methods do not show up in the coverage report, it's easier to see what code, which was actually written by a developer, needs additional JUnit tests. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) I have taken this patch: https://sourceforge.net/tracker/?func=detail&aid=2035169&group_id=130558 &atid=720017 and merged it into the 1.9.4.1 baseline. This patch provides the "--ignoreTrivial" flag. This analyzes the bytes code of the method and determines if it is a simple getter/setter method or constructor and if so, it is excluded from the coverage report. If it has additional logic in the method, then it is not ignored. In addition, the flag has to be set to enable this functionality. This should be a pretty safe change. This patch also contains a "--ignoreMethod" which is a list of regular expressions of method names to ignore. I don't really agree with this approach so this has been removed from my patch merge. I have also added a new flag "--ignoreMethodAnnotations" which takes a list of annotation class names. (i.e. com.lwlmco.ross.server.util.IgnoreInCoverageReport) If one of the annotations specified by this list is found on a method, then it will be ignored in the coverage report. This allows a project to use whatever annotation they desire to ignore methods in the coverage report. Developers are forced to consciously specify a method that should not show up in the coverage report (and this should be caught in code reviews). Again, if this flag is not set, it will not modify current behavior, so it's a safe change to make. I would like to get this into the project baseline and would like to know what is required to do so. Thanks, -- Tad |
|
From: Tad S. <ts...@lw...> - 2010-06-01 17:56:33
|
Correct. --ignoreTrivial should never exclude the equals, hashCode, or toString methods. I put my project's custom annotation on all generated equals, hashCode, and toString methods. That gets me the rest of the way there. If you wish to run the build without ignoring these methods, then don't include the --ignoreMethodAnnotations flag. It's very flexible, so it can be used for projects with a variety of requirements. Thanks, -- Tad From: Bennett, Jeffrey [mailto:JJB...@On...] Sent: Tuesday, June 01, 2010 11:50 AM To: Tad Smith; cob...@li... Subject: RE: [Cobertura-devel] Excluding Methods from coverage report Speaking only for myself, I'd hate --ignoreTrivial (but I can simply choose not to use it). 1.) I frequently find myself looking at coverage reports to find dead-code. Often, the dead code is in these simple methods so I'd hate to lose this capability. 2.) It sounds like equals, hashCode and toString will never be excluded by ignoreTrivial, so this solution only gets you part way to your goal (albeit, perhaps a big step) The ignoreMethodAnnotations looks intriguing. Does that mean that by adding an annotation to a method, you can make cobertura ignore any arbitrary method? That would be fantastic. ________________________________________ From: Tad Smith [mailto:ts...@lw...] Sent: Tuesday, June 01, 2010 11:30 AM To: cob...@li... Subject: [Cobertura-devel] Excluding Methods from coverage report There seems to be a real need to be able to exclude certain methods from the coverage report and multiple patch to do so have been submitted over the years, but none seem to have been included in the baseline. On my project we use Eclipse to generate getters/setters, hashCode(), equals(), and toString() methods. This is a real timesaver. Since these methods are generated, we have no desire to ensure that they are unit tested via JUnit. However, they are currently showing up in our Cobertura coverage report. The affect of this is that they are adding "noise" to the report. When these generated methods do not show up in the coverage report, it's easier to see what code, which was actually written by a developer, needs additional JUnit tests. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) I have taken this patch: https://sourceforge.net/tracker/?func=detail&aid=2035169&group_id=130558&atid=720017 and merged it into the 1.9.4.1 baseline. This patch provides the "--ignoreTrivial" flag. This analyzes the bytes code of the method and determines if it is a simple getter/setter method or constructor and if so, it is excluded from the coverage report. If it has additional logic in the method, then it is not ignored. In addition, the flag has to be set to enable this functionality. This should be a pretty safe change. This patch also contains a "--ignoreMethod" which is a list of regular expressions of method names to ignore. I don't really agree with this approach so this has been removed from my patch merge. I have also added a new flag "--ignoreMethodAnnotations" which takes a list of annotation class names. (i.e. com.lwlmco.ross.server.util.IgnoreInCoverageReport) If one of the annotations specified by this list is found on a method, then it will be ignored in the coverage report. This allows a project to use whatever annotation they desire to ignore methods in the coverage report. Developers are forced to consciously specify a method that should not show up in the coverage report (and this should be caught in code reviews). Again, if this flag is not set, it will not modify current behavior, so it's a safe change to make. I would like to get this into the project baseline and would like to know what is required to do so. Thanks, -- Tad |
|
From: Tad S. <ts...@lw...> - 2010-06-01 15:42:50
|
There seems to be a real need to be able to exclude certain methods from the coverage report and multiple patch to do so have been submitted over the years, but none seem to have been included in the baseline. On my project we use Eclipse to generate getters/setters, hashCode(), equals(), and toString() methods. This is a real timesaver. Since these methods are generated, we have no desire to ensure that they are unit tested via JUnit. However, they are currently showing up in our Cobertura coverage report. The affect of this is that they are adding "noise" to the report. When these generated methods do not show up in the coverage report, it's easier to see what code, which was actually written by a developer, needs additional JUnit tests. (Note: This is not a mechanism to boost coverage %, because in many cases the coverage % goes down when these methods are removed from the report.) I have taken this patch: https://sourceforge.net/tracker/?func=detail&aid=2035169&group_id=130558&atid=720017 and merged it into the 1.9.4.1 baseline. This patch provides the "--ignoreTrivial" flag. This analyzes the bytes code of the method and determines if it is a simple getter/setter method or constructor and if so, it is excluded from the coverage report. If it has additional logic in the method, then it is not ignored. In addition, the flag has to be set to enable this functionality. This should be a pretty safe change. This patch also contains a "--ignoreMethod" which is a list of regular expressions of method names to ignore. I don't really agree with this approach so this has been removed from my patch merge. I have also added a new flag "--ignoreMethodAnnotations" which takes a list of annotation class names. (i.e. com.lwlmco.ross.server.util.IgnoreInCoverageReport) If one of the annotations specified by this list is found on a method, then it will be ignored in the coverage report. This allows a project to use whatever annotation they desire to ignore methods in the coverage report. Developers are forced to consciously specify a method that should not show up in the coverage report (and this should be caught in code reviews). Again, if this flag is not set, it will not modify current behavior, so it's a safe change to make. I would like to get this into the project baseline and would like to know what is required to do so. Thanks, -- Tad |
|
From: Richard A. <ric...@go...> - 2010-05-26 00:48:21
|
Hi
DirSet usage in the <cobertura-instrument/> ant tak seems to have been
introduced between Cobertura 1.9 and 1.9.4.1 to complement FileSet
processing.
I would like to use filesets to specify a set of files for
instrumentation and dirsets to specify a set of directories
(containing classes) for processing:
<fileset dir="${classes}">
<include name="**/somepackage/*.class"/>
</fileset>
<dirset dir="${classes}/anotherpackage">
<include name="util"/>
<include name="support"/>
</dirset>
In the case of filesets, the filenames I get back have absolute names
which are a concatenation of the base directory ${classes} and the
concrete included files, which allows locating the file within the
filesystem.
In the case of dirsets, the filenames I get back are names which only
include the concrete included directories relative to the basedir; the
base directory ${classes}/another package is not appended. This means
that the list of directories passed to commandLine builder are missing
their basename. For example:
[cobertura-instrument] DEBUG parseArguments, arguments:
[cobertura-instrument] DEBUG parseArguments, arg[0] = --destination
[cobertura-instrument] DEBUG parseArguments, arg[1] =
/tmp/cobertura-1.9.4.1/examples/basic/instrumented
[cobertura-instrument] DEBUG parseArguments, arg[2] = --ignore
[cobertura-instrument] DEBUG parseArguments, arg[3] = org.apache.log4j.*
[cobertura-instrument] DEBUG parseArguments, arg[4] = com/example/complicated
[cobertura-instrument] DEBUG parseArguments, arg[5] = --basedir
[cobertura-instrument] DEBUG parseArguments, arg[6] =
/tmp/cobertura-1.9.4.1/examples/basic/classes
[cobertura-instrument] DEBUG parseArguments, arg[7] =
com/example/simple/Simple.class
The directory com/example/complicated has a basedir of
/tmp/cobertura-1.9.4.1/examples/basic/classes and this is getting left
behind. Consequently, none of the classes in that directory are
processed.
The code which processes directories is in InstrumentTask.java:
protected void createArgumentsForFilesets( CommandLineBuilder
builder) throws IOException {
Iterator iter = fileSets.iterator();
boolean filesetFound = false;
while (iter.hasNext())
{
AbstractFileSet fileSet = (AbstractFileSet)iter.next();
if (fileSet instanceof FileSet)
{
filesetFound = true;
builder.addArg("--basedir", baseDir(fileSet));
createArgumentsForFilenames( builder, getFilenames(fileSet));
}
else
{
if (filesetFound)
{
/*
* Once --basedir has been used, it cannot be undone without changes to the
* Main methods. So, any dirsets have to come before filesets.
*/
throw new BuildException("Dirsets have to come before filesets");
}
createArgumentsForFilenames( builder,
getDirectoryScanner(fileSet).getIncludedDirectories());
}
}
}
The problems is that
getDirectoryScanner(fileSet).getIncludedDirectories() returns
directory names which are relative to the basedir specified on the
DirSet element. I believe that the DirSet basedir needs to be
prepended to each included directory before the arguments are created.
Without this, a relative directory name is useless unless the basedir
is somehow specified, which it isn't in the case of directory names.
WDYT?
Richard
|
|
From: John W. L. <Joh...@sa...> - 2010-05-25 19:50:22
|
I think the idea is that if you had code similar to this:
try {
//something
} catch (Exception e) {
LOGGER.info("Something bad happened");
}
You would not necessarily care to test if something was really logged when an exception occurred.
So, you can <ignore regex="org.apache.log4j.*" /> which will essentially cause Cobertura to ignore the line that has the LOGGER.info() call (only since it is the only thing on the line).
I am not certain, but I suppose the --ignoreBranches idea was to do something similar with code like:
if (!success) {
LOGGER.info("Something bad happened");
}
Basically, it would keep the line from being highlighted with red in the coverage report, and it would keep the line from changing the line or branch coverage percentage.
John
-----Original Message-----
From: Richard Achmatowicz [mailto:ric...@go...]
Sent: Tuesday, May 25, 2010 12:55 PM
To: cob...@li...
Subject: Re: [Cobertura-devel] Question on --ignore
Hi
I had a look at the implementation of --ignore and --ignoreBranches
and it looks like this code needs to be the subject of a bug report.
I'm looking at the sources in the tag for Cobertura 1.9.
1. The regular expression passed via --ignore is used in
FirstPassMethodInstrumenter and SecondPassMethodInstrumenter, in the
ASM class traversal method visitMethodInsn. I don't see any other uses
of it. The code looks like this:
public visitMethodInsn(int opcode, String owner, String name, String desc) {
super.visitMethodInsn(opcode, owner, name, desc) ;
if (RegexUtil.matches(ignoreRegexs, owner)) {
classData.removeLine(currentLine) ;
}
}
This bytecode instruction is responsible for executing the method
'name' of the object 'owner', called from within an instrumented
class. The string owner is an internal object name (e.g.
java/lang/String) used by ASM.
So, from what I can tell, --ignore will only have an effect if the
regexp is one which matches an internal object name (which users
probably aren't used to dealing with) and the effect is to remove the
current line from the classData file for that class (not sure what
impact this has on what happens downstream). Also, if a match does
occur, the effect is not to "filter out certain lines of source code"
but potentially to filter out all method calls to an object whose
internal object name matches the regular expression and is called from
within an instrumented class.
Here is some debugging output showing the calls:
[cobertura-instrument] DEBUG visit, executing visit()
[cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
= java/lang/Object
[cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
= org/apache/log4j/Logger
[cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn:
removing line from org/apache/log4j/Logger:isDebugEnabled
[cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
= java/lang/StringBuilder
2. The regular expression passed in via -ignoreBranches seems to do
nothing at all as the expression isn't processed in either
FirstPassMethodInstrumenter and SecondPassMethodInstrumenter.
Furthermore, how are you going to specify a branch using a regular
expression? I'm not even sure what the term branch is intended to mean
in the context of Cobertura. Branching is usually associated with
choices taken in control flow based on conditions (and not for example
unconditional jumps in control flow).
So i'm still puzzled as to:
(i) why these options were specified in the first place, what they
were intended to achieve and how they were intended to be used
(ii) how removing these lines from classData was intended to impact
downstream processing
Before filing a bug report, can anyone tell me what the intention was here?
Richard
On Thu, May 20, 2010 at 6:20 PM, Richard Achmatowicz
<ric...@go...> wrote:
> Hi
>
> Just getting started with Cobertura. A few questions centered around
> --ignore and --ignoreBranches:
>
> 1. The description of the --ignore option for cobertura-instrument.bat is:
> Description: "Specify a regular expression to filter out certain lines
> of your source code. This is useful for ignoring logging statements.
> You can have as many --ignore statements as you want"
> Default value: "no files are ignored"
>
> Can --ignore really specify lines of source code? Or is it limited to
> specifying classes, as in the example given (--ignore
> "org.apache.log4j.*")
>
> 2. In instrument.Main.java and in ant.InstrumentTask.java, there is
> processing for --ignoreBranches and <ignoreBranches regex=... />, but
> I can't find any related documentation.
>
> How do we use regexs to specify branches in this case?
>
> 3. I was going to ask what the difference is between using --ignore
> and --ignoreBranches versus excluding a class. But if --ignore and
> --ignoreBranches can get down to line and branch level, I guess I have
> my answer.
>
> Richard
>
------------------------------------------------------------------------------
_______________________________________________
Cobertura-devel mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobertura-devel
|
|
From: Richard A. <ric...@go...> - 2010-05-25 19:46:21
|
And of course org.apache.log4j.* is a regular expression which will
match internal names such as org/apache/log4j/... :-(
On Tue, May 25, 2010 at 12:54 PM, Richard Achmatowicz
<ric...@go...> wrote:
> Hi
>
> I had a look at the implementation of --ignore and --ignoreBranches
> and it looks like this code needs to be the subject of a bug report.
> I'm looking at the sources in the tag for Cobertura 1.9.
>
> 1. The regular expression passed via --ignore is used in
> FirstPassMethodInstrumenter and SecondPassMethodInstrumenter, in the
> ASM class traversal method visitMethodInsn. I don't see any other uses
> of it. The code looks like this:
>
> public visitMethodInsn(int opcode, String owner, String name, String desc) {
> super.visitMethodInsn(opcode, owner, name, desc) ;
> if (RegexUtil.matches(ignoreRegexs, owner)) {
> classData.removeLine(currentLine) ;
> }
> }
>
> This bytecode instruction is responsible for executing the method
> 'name' of the object 'owner', called from within an instrumented
> class. The string owner is an internal object name (e.g.
> java/lang/String) used by ASM.
>
> So, from what I can tell, --ignore will only have an effect if the
> regexp is one which matches an internal object name (which users
> probably aren't used to dealing with) and the effect is to remove the
> current line from the classData file for that class (not sure what
> impact this has on what happens downstream). Also, if a match does
> occur, the effect is not to "filter out certain lines of source code"
> but potentially to filter out all method calls to an object whose
> internal object name matches the regular expression and is called from
> within an instrumented class.
>
> Here is some debugging output showing the calls:
> [cobertura-instrument] DEBUG visit, executing visit()
> [cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
> = java/lang/Object
> [cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
> = org/apache/log4j/Logger
> [cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn:
> removing line from org/apache/log4j/Logger:isDebugEnabled
> [cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
> = java/lang/StringBuilder
>
>
> 2. The regular expression passed in via -ignoreBranches seems to do
> nothing at all as the expression isn't processed in either
> FirstPassMethodInstrumenter and SecondPassMethodInstrumenter.
>
> Furthermore, how are you going to specify a branch using a regular
> expression? I'm not even sure what the term branch is intended to mean
> in the context of Cobertura. Branching is usually associated with
> choices taken in control flow based on conditions (and not for example
> unconditional jumps in control flow).
>
> So i'm still puzzled as to:
> (i) why these options were specified in the first place, what they
> were intended to achieve and how they were intended to be used
> (ii) how removing these lines from classData was intended to impact
> downstream processing
>
> Before filing a bug report, can anyone tell me what the intention was here?
>
> Richard
>
> On Thu, May 20, 2010 at 6:20 PM, Richard Achmatowicz
> <ric...@go...> wrote:
>> Hi
>>
>> Just getting started with Cobertura. A few questions centered around
>> --ignore and --ignoreBranches:
>>
>> 1. The description of the --ignore option for cobertura-instrument.bat is:
>> Description: "Specify a regular expression to filter out certain lines
>> of your source code. This is useful for ignoring logging statements.
>> You can have as many --ignore statements as you want"
>> Default value: "no files are ignored"
>>
>> Can --ignore really specify lines of source code? Or is it limited to
>> specifying classes, as in the example given (--ignore
>> "org.apache.log4j.*")
>>
>> 2. In instrument.Main.java and in ant.InstrumentTask.java, there is
>> processing for --ignoreBranches and <ignoreBranches regex=... />, but
>> I can't find any related documentation.
>>
>> How do we use regexs to specify branches in this case?
>>
>> 3. I was going to ask what the difference is between using --ignore
>> and --ignoreBranches versus excluding a class. But if --ignore and
>> --ignoreBranches can get down to line and branch level, I guess I have
>> my answer.
>>
>> Richard
>>
>
|
|
From: Richard A. <ric...@go...> - 2010-05-25 16:54:37
|
Hi
I had a look at the implementation of --ignore and --ignoreBranches
and it looks like this code needs to be the subject of a bug report.
I'm looking at the sources in the tag for Cobertura 1.9.
1. The regular expression passed via --ignore is used in
FirstPassMethodInstrumenter and SecondPassMethodInstrumenter, in the
ASM class traversal method visitMethodInsn. I don't see any other uses
of it. The code looks like this:
public visitMethodInsn(int opcode, String owner, String name, String desc) {
super.visitMethodInsn(opcode, owner, name, desc) ;
if (RegexUtil.matches(ignoreRegexs, owner)) {
classData.removeLine(currentLine) ;
}
}
This bytecode instruction is responsible for executing the method
'name' of the object 'owner', called from within an instrumented
class. The string owner is an internal object name (e.g.
java/lang/String) used by ASM.
So, from what I can tell, --ignore will only have an effect if the
regexp is one which matches an internal object name (which users
probably aren't used to dealing with) and the effect is to remove the
current line from the classData file for that class (not sure what
impact this has on what happens downstream). Also, if a match does
occur, the effect is not to "filter out certain lines of source code"
but potentially to filter out all method calls to an object whose
internal object name matches the regular expression and is called from
within an instrumented class.
Here is some debugging output showing the calls:
[cobertura-instrument] DEBUG visit, executing visit()
[cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
= java/lang/Object
[cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
= org/apache/log4j/Logger
[cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn:
removing line from org/apache/log4j/Logger:isDebugEnabled
[cobertura-instrument] DEBUG visitMethodInsn, visitMethodInsn: owner
= java/lang/StringBuilder
2. The regular expression passed in via -ignoreBranches seems to do
nothing at all as the expression isn't processed in either
FirstPassMethodInstrumenter and SecondPassMethodInstrumenter.
Furthermore, how are you going to specify a branch using a regular
expression? I'm not even sure what the term branch is intended to mean
in the context of Cobertura. Branching is usually associated with
choices taken in control flow based on conditions (and not for example
unconditional jumps in control flow).
So i'm still puzzled as to:
(i) why these options were specified in the first place, what they
were intended to achieve and how they were intended to be used
(ii) how removing these lines from classData was intended to impact
downstream processing
Before filing a bug report, can anyone tell me what the intention was here?
Richard
On Thu, May 20, 2010 at 6:20 PM, Richard Achmatowicz
<ric...@go...> wrote:
> Hi
>
> Just getting started with Cobertura. A few questions centered around
> --ignore and --ignoreBranches:
>
> 1. The description of the --ignore option for cobertura-instrument.bat is:
> Description: "Specify a regular expression to filter out certain lines
> of your source code. This is useful for ignoring logging statements.
> You can have as many --ignore statements as you want"
> Default value: "no files are ignored"
>
> Can --ignore really specify lines of source code? Or is it limited to
> specifying classes, as in the example given (--ignore
> "org.apache.log4j.*")
>
> 2. In instrument.Main.java and in ant.InstrumentTask.java, there is
> processing for --ignoreBranches and <ignoreBranches regex=... />, but
> I can't find any related documentation.
>
> How do we use regexs to specify branches in this case?
>
> 3. I was going to ask what the difference is between using --ignore
> and --ignoreBranches versus excluding a class. But if --ignore and
> --ignoreBranches can get down to line and branch level, I guess I have
> my answer.
>
> Richard
>
|
|
From: Jiří M. <jir...@gm...> - 2010-05-21 06:22:55
|
Hi all,
The problem with branch coverage is that it is more condition coverage.
Therefore it coveres conditional jumps in bytecode. Therefore it is not
necessary to have boolean evalution in if statement, John.
Folowing method has also condition coverage on its only line:
boolean greater(int a, int b) {
return a > b;
}
But if I look at the example provided there I see only one conditional jump
and therefore I don't understand why there is any branch coverage in the
"else" line. But the only relevant thing to decide is to view how is the
code compiled into byte code. Maybe there is some conditional jump.
The same problem is with:
protected static final Class clazz = Class.forName("java.lang.Object")
that is compiled using conditional jump therefore we can't see any there ...
Jirka
On Fri, May 21, 2010 at 7:56 AM, John W. Lewis <Joh...@sa...> wrote:
>
> I am confused.
>
> selenium.isTextPresent() is a method that returns a boolean, but it is not
> a conditional unless it is in an if statement, right? There is only one if
> statement in this block of code, so the way I see it, there is only one
> conditional (if (yesNo)).
>
> John
>
>
> -----Original Message-----
> From: Jim Showalter [mailto:ji...@ji...]
> Sent: Friday, May 21, 2010 1:46 AM
> To: Jake Cobb; John W. Lewis
> Cc: cob...@li...; Anton Trapp
> Subject: Re: [Cobertura-devel] branch coverage of two function calls???
>
> Okay, I reread the original question, and it's different. Sorry about that.
>
> Anton, for your test to hit all four branches, it has to do this:
>
> 1) Make sure text "secure page" is present.
>
> 2) Call mustBeAuthenticated with yesNo true.
>
> 3) Call mustBeAuthenticated with yesNo false.
>
> 4) Make sure text "secure page" is not present.
>
> 5) Call mustBeAuthenticated with yesNo true.
>
> 6) Call mustBeAuthenticated with yesNo false.
>
> That will cover all four branches.
>
> Does your test do that?
>
> if (yesNo) {
> verifyTrue(selenium.isTextPresent("secure page"));
> } else {
> verifyFalse(selenium.isTextPresent("secure page")); <-- THIS LINE???
> }
>
> ----- Original Message -----
> From: "Jim Showalter" <ji...@ji...>
> To: "Jake Cobb" <jak...@ga...>; "John W. Lewis"
> <Joh...@sa...>
> Cc: <cob...@li...>; "Anton Trapp"
> <tm...@al...>
> Sent: Thursday, May 20, 2010 10:34 PM
> Subject: Re: [Cobertura-devel] branch coverage of two function calls???
>
>
> > Er, no.
> >
> > Did anyone read my response to Anton's question?
> >
> > If you have this structure:
> >
> > if (cond(foo)) {
> > bar
> > } else if (!cond(foo)) {
> > baz
> > }
> >
> > then it is impossible to make the code take all four possible branches.
> >
> > Try a truth table with the above example.
> >
> > Set foo = true. What do you get? You get the first condition true,
> leading
> > to bar
> >
> > Set foo = false. What do you get? You get the first condition false and
> > the second condition true, leading to baz.
> >
> > You have now gotten 100% statement coverage.
> >
> > And you have also gotten 100% branch coverage on the first conditional.
> >
> > But you can never, ever get 100% branch coverage on the second
> > conditional, because you can only reach the second conditional if foo is
> > false. If foo is true, you'll never get to the second conditional.
> >
> > Which means you can never get !cond(foo) to evaluate to false, so if it
> > gets to the else-if it will never not result in baz.
> >
> > If you get to the second conditional, you will always get to baz.
> > Guaranteed. Thus exactly 50% branch coverage despite 100% statement
> > coverage.
> >
> > Please try this yourself. There is nothing wrong with Cobertura.
> >
> > ----- Original Message -----
> > From: "Jake Cobb" <jak...@ga...>
> > To: "John W. Lewis" <Joh...@sa...>
> > Cc: <cob...@li...>; "Anton Trapp"
> > <tm...@al...>
> > Sent: Thursday, May 20, 2010 11:10 AM
> > Subject: Re: [Cobertura-devel] branch coverage of two function calls???
> >
> >
> > 2010/5/20 John W. Lewis <Joh...@sa...>
> >
> >>
> >>
> >> It definitely looks like there is a problem. The line was exercised
> >> twice,
> >> so the only reason it would be red is if the branch coverage was not
> >> 100%.
> >>
> >>
> >>
> >
> > It looks like a couple of problems. First, the branch on line 85 is
> > definitely covered. It seems to be marked correctly in the code display
> > (not red), but the branch coverage overview says no branches are covered.
> > If both screenshots are from the same report, the overview should show at
> > least 1 branch covered. Anton, can you confirm these screenshots were
> > taken
> > from the same report instance?
> >
> > Second, if all branches are attributed to the single method we're shown,
> > why
> > does it think there is more than one branch in that method?
> > Passing/returning a boolean value is not a branch in the bytecode
> produced
> > by the Sun compiler.
> >
> > e.g. this code...
> >
> > public void doSomething(boolean yesNo) {
> > if( yesNo ) {
> > boolTest(getBool());
> > } else {
> > boolTest2(getBool());
> > }
> > }
> >
> > ... produces this bytecode ...
> >
> > public void doSomething(boolean);
> > Code:
> > 0: iload_1
> > 1: ifeq 15
> > 4: aload_0
> > 5: aload_0
> > 6: invokevirtual #2; //Method getBool:()Z
> > 9: invokevirtual #3; //Method boolTest:(Z)V
> > 12: goto 23
> > 15: aload_0
> > 16: aload_0
> > 17: invokevirtual #2; //Method getBool:()Z
> > 20: invokevirtual #4; //Method boolTest2:(Z)V
> > 23: return
> >
> > ... which has only one branch.
> >
> >> What version of Java are you using?
> >>
> >>
> >>
> >> When you hover over the red line, does the popup say anything?
> >>
> >>
> >>
> >> Are there any annotations in the source file?
> >>
> >>
> >>
> >> I wonder if the problem can be reproduced with a smaller source file
> that
> >> you can share with us. Or, can you send the corresponding class file?
> >> Or,
> >> use a decompiler such as Jad and show us the decompiled source?
> >>
> >>
> >>
> >> John
> >>
> >>
> >>
> >
> > Anton,
> >
> > In addition to John's questions above, are you using any other
> > bytecode-modifying processing (e.g. AspectJ)? Are you using a compiler
> > other than Sun's?
> >
> > -Jake
> >
> >
> >> *From:* Anton Trapp [mailto:tm...@al...]
> >> *Sent:* Thursday, May 20, 2010 9:59 AM
> >> *To:* cob...@li...
> >> *Subject:* Re: [Cobertura-devel] branch coverage of two function
> calls???
> >>
> >>
> >>
> >> Hi!
> >>
> >>
> >>
> >> Thank you for your fast answer! As I said, I do run tests with
> true/false
> >> and the if statement is not even mentioned in the branches:
> >>
> >>
> >>
> >> Overview:
> >>
> >>
> >>
> >>
> >>
> >> code:
> >>
> >>
> >>
> >>
> >>
> >> So yes/No is working, but line 88 has line coverage but no branch
> >> coverage.
> >> I am understanding my question, but I don't understand what cobertura
> >> needs
> >> to branch in line 88 where there is not even a control structure...
> >>
> >>
> >>
> >> Regards,
> >>
> >> Anton
> >>
> >>
> >>
> >> Am 20.05.2010 um 15:39 schrieb Alejandro Pérez García:
> >>
> >>
> >>
> >> Hi
> >>
> >> I'm sorry, but I thikn that I don't understand your question.
> >>
> >> If you want to cover the "else" sentence (the sentence you marked with
> >> "THIS LINE") you only have to do "false" the yesNo expresion.
> >>
> >> I don't understand where is the problem.
> >>
> >> Regards
> >>
> >>
> >>
> >> 2010/5/20 Anton Trapp <tm...@al...>
> >>
> >> Hi!
> >>
> >>
> >>
> >> How can I cover the 4 branches of:
> >>
> >>
> >>
> >> if (yesNo) {
> >>
> >> verifyTrue(selenium.isTextPresent("secure page"));
> >>
> >> } else {
> >>
> >> verifyFalse(selenium.isTextPresent("secure page")); <--
> THIS
> >> LINE???
> >>
> >> }
> >>
> >>
> >>
> >> Code coverage is 100%, this test is called multiple times (yes I do
> >> perform
> >> a code coverage of the tests, please do NOT ask why...) with yesNo both
> >> true
> >> and false. So how can I test the 4 branches in the function calls that I
> >> don't even see and why are there no function calls in the second line
> >> which
> >> is almost identical.
> >>
> >>
> >>
> >> I always thought that branches are only for control structures like if,
> >> ...?
> >>
> >>
> >>
> >> Anybody can help me?
> >>
> >>
> >>
> >> Thank you very much in advance!
> >>
> >>
> >>
> >> Regards,
> >>
> >> Anton
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Cobertura-devel mailing list
> >> Cob...@li...
> >> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> >>
> >>
> >>
> >>
> >> --
> >> Alejandro Pérez García
> >> Socio fundador de Autentia y www.adictosaltrabajo.com
> >> (Formación, Consultoría, Desarrollo de sistemas transaccionales)
> >> mailto:ale...@au...
> >> Tel.: 655 99 11 75
> >>
> >> Autentia Real Business Solutions S.L.
> >> "Soporte a Desarrollo"
> >> http://www.autentia.com
> >>
> >>
> >>
> >> Este mensaje, y en su caso cualquier fichero anexo al mismo, puede
> >> contener
> >> información confidencial y/o privilegiada, siendo para uso exclusivo del
> >> destinatario. Si Vd. no es el destinatario o lo ha recibido por error,
> >> por
> >> favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente
> >> prohibido por la legislación vigente realizar sin autorización cualquier
> >> copia, revelación o distribución del contenido de este mensaje sin la
> >> autorización expresa del remitente. Las opiniones expresadas en este
> >> correo
> >> son las de su autor y no son, necesariamente, compartidas por Autentia
> >> Real
> >> Business Solutions S.L.
> >>
> >> This e-mail, and in the case of any file annexed to it, may contain
> >> confidential and/or privileged information, and it is exclusively for
> the
> >> use of the addresses of the message. If you are not the intended
> >> recipient
> >> (or have received this e-mail in error), please notify the sender
> >> immediately and destroy this e-mail. Any unauthorised copying,
> disclosure
> >> or
> >> distribution of the material in this e-mail is strictly forbidden by
> >> current
> >> legislation. The points of view expressed in this e-mail are solely
> those
> >> of
> >> the author and may not necessarily be from, or supported by, Autentia
> >> Real
> >> Business Solutions S.L.
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Cobertura-devel mailing list
> >> Cob...@li...
> >> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> >>
> >>
> >
> >
> >
> >
> --------------------------------------------------------------------------------
> >
> >
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> >
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
--
Jiří Mareš
|
|
From: Jim S. <ji...@ji...> - 2010-05-21 06:12:01
|
I'm assuming verify acts like it does in JUnit.
If that assumption is correct, the verify call will throw or not depending
on the value returned by isTextPresent.
If yesNo is only false when the text is present, then the second branch will
always throw and never exit normally, and I think that will show one branch
unexercised.
It would help to see the full test case.
----- Original Message -----
From: "John W. Lewis" <Joh...@sa...>
To: "Jim Showalter" <ji...@ji...>; "Jake Cobb" <jak...@ga...>
Cc: <cob...@li...>; "Anton Trapp"
<tm...@al...>
Sent: Thursday, May 20, 2010 10:56 PM
Subject: RE: [Cobertura-devel] branch coverage of two function calls???
>
> I am confused.
>
> selenium.isTextPresent() is a method that returns a boolean, but it is not
> a conditional unless it is in an if statement, right? There is only one
> if statement in this block of code, so the way I see it, there is only one
> conditional (if (yesNo)).
>
> John
>
>
> -----Original Message-----
> From: Jim Showalter [mailto:ji...@ji...]
> Sent: Friday, May 21, 2010 1:46 AM
> To: Jake Cobb; John W. Lewis
> Cc: cob...@li...; Anton Trapp
> Subject: Re: [Cobertura-devel] branch coverage of two function calls???
>
> Okay, I reread the original question, and it's different. Sorry about
> that.
>
> Anton, for your test to hit all four branches, it has to do this:
>
> 1) Make sure text "secure page" is present.
>
> 2) Call mustBeAuthenticated with yesNo true.
>
> 3) Call mustBeAuthenticated with yesNo false.
>
> 4) Make sure text "secure page" is not present.
>
> 5) Call mustBeAuthenticated with yesNo true.
>
> 6) Call mustBeAuthenticated with yesNo false.
>
> That will cover all four branches.
>
> Does your test do that?
>
> if (yesNo) {
> verifyTrue(selenium.isTextPresent("secure page"));
> } else {
> verifyFalse(selenium.isTextPresent("secure page")); <-- THIS LINE???
> }
>
> ----- Original Message -----
> From: "Jim Showalter" <ji...@ji...>
> To: "Jake Cobb" <jak...@ga...>; "John W. Lewis"
> <Joh...@sa...>
> Cc: <cob...@li...>; "Anton Trapp"
> <tm...@al...>
> Sent: Thursday, May 20, 2010 10:34 PM
> Subject: Re: [Cobertura-devel] branch coverage of two function calls???
>
>
>> Er, no.
>>
>> Did anyone read my response to Anton's question?
>>
>> If you have this structure:
>>
>> if (cond(foo)) {
>> bar
>> } else if (!cond(foo)) {
>> baz
>> }
>>
>> then it is impossible to make the code take all four possible branches.
>>
>> Try a truth table with the above example.
>>
>> Set foo = true. What do you get? You get the first condition true,
>> leading
>> to bar
>>
>> Set foo = false. What do you get? You get the first condition false and
>> the second condition true, leading to baz.
>>
>> You have now gotten 100% statement coverage.
>>
>> And you have also gotten 100% branch coverage on the first conditional.
>>
>> But you can never, ever get 100% branch coverage on the second
>> conditional, because you can only reach the second conditional if foo is
>> false. If foo is true, you'll never get to the second conditional.
>>
>> Which means you can never get !cond(foo) to evaluate to false, so if it
>> gets to the else-if it will never not result in baz.
>>
>> If you get to the second conditional, you will always get to baz.
>> Guaranteed. Thus exactly 50% branch coverage despite 100% statement
>> coverage.
>>
>> Please try this yourself. There is nothing wrong with Cobertura.
>>
>> ----- Original Message -----
>> From: "Jake Cobb" <jak...@ga...>
>> To: "John W. Lewis" <Joh...@sa...>
>> Cc: <cob...@li...>; "Anton Trapp"
>> <tm...@al...>
>> Sent: Thursday, May 20, 2010 11:10 AM
>> Subject: Re: [Cobertura-devel] branch coverage of two function calls???
>>
>>
>> 2010/5/20 John W. Lewis <Joh...@sa...>
>>
>>>
>>>
>>> It definitely looks like there is a problem. The line was exercised
>>> twice,
>>> so the only reason it would be red is if the branch coverage was not
>>> 100%.
>>>
>>>
>>>
>>
>> It looks like a couple of problems. First, the branch on line 85 is
>> definitely covered. It seems to be marked correctly in the code display
>> (not red), but the branch coverage overview says no branches are covered.
>> If both screenshots are from the same report, the overview should show at
>> least 1 branch covered. Anton, can you confirm these screenshots were
>> taken
>> from the same report instance?
>>
>> Second, if all branches are attributed to the single method we're shown,
>> why
>> does it think there is more than one branch in that method?
>> Passing/returning a boolean value is not a branch in the bytecode
>> produced
>> by the Sun compiler.
>>
>> e.g. this code...
>>
>> public void doSomething(boolean yesNo) {
>> if( yesNo ) {
>> boolTest(getBool());
>> } else {
>> boolTest2(getBool());
>> }
>> }
>>
>> ... produces this bytecode ...
>>
>> public void doSomething(boolean);
>> Code:
>> 0: iload_1
>> 1: ifeq 15
>> 4: aload_0
>> 5: aload_0
>> 6: invokevirtual #2; //Method getBool:()Z
>> 9: invokevirtual #3; //Method boolTest:(Z)V
>> 12: goto 23
>> 15: aload_0
>> 16: aload_0
>> 17: invokevirtual #2; //Method getBool:()Z
>> 20: invokevirtual #4; //Method boolTest2:(Z)V
>> 23: return
>>
>> ... which has only one branch.
>>
>>> What version of Java are you using?
>>>
>>>
>>>
>>> When you hover over the red line, does the popup say anything?
>>>
>>>
>>>
>>> Are there any annotations in the source file?
>>>
>>>
>>>
>>> I wonder if the problem can be reproduced with a smaller source file
>>> that
>>> you can share with us. Or, can you send the corresponding class file?
>>> Or,
>>> use a decompiler such as Jad and show us the decompiled source?
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>
>> Anton,
>>
>> In addition to John's questions above, are you using any other
>> bytecode-modifying processing (e.g. AspectJ)? Are you using a compiler
>> other than Sun's?
>>
>> -Jake
>>
>>
>>> *From:* Anton Trapp [mailto:tm...@al...]
>>> *Sent:* Thursday, May 20, 2010 9:59 AM
>>> *To:* cob...@li...
>>> *Subject:* Re: [Cobertura-devel] branch coverage of two function
>>> calls???
>>>
>>>
>>>
>>> Hi!
>>>
>>>
>>>
>>> Thank you for your fast answer! As I said, I do run tests with
>>> true/false
>>> and the if statement is not even mentioned in the branches:
>>>
>>>
>>>
>>> Overview:
>>>
>>>
>>>
>>>
>>>
>>> code:
>>>
>>>
>>>
>>>
>>>
>>> So yes/No is working, but line 88 has line coverage but no branch
>>> coverage.
>>> I am understanding my question, but I don't understand what cobertura
>>> needs
>>> to branch in line 88 where there is not even a control structure...
>>>
>>>
>>>
>>> Regards,
>>>
>>> Anton
>>>
>>>
>>>
>>> Am 20.05.2010 um 15:39 schrieb Alejandro Pérez García:
>>>
>>>
>>>
>>> Hi
>>>
>>> I'm sorry, but I thikn that I don't understand your question.
>>>
>>> If you want to cover the "else" sentence (the sentence you marked with
>>> "THIS LINE") you only have to do "false" the yesNo expresion.
>>>
>>> I don't understand where is the problem.
>>>
>>> Regards
>>>
>>>
>>>
>>> 2010/5/20 Anton Trapp <tm...@al...>
>>>
>>> Hi!
>>>
>>>
>>>
>>> How can I cover the 4 branches of:
>>>
>>>
>>>
>>> if (yesNo) {
>>>
>>> verifyTrue(selenium.isTextPresent("secure page"));
>>>
>>> } else {
>>>
>>> verifyFalse(selenium.isTextPresent("secure page")); <--
>>> THIS
>>> LINE???
>>>
>>> }
>>>
>>>
>>>
>>> Code coverage is 100%, this test is called multiple times (yes I do
>>> perform
>>> a code coverage of the tests, please do NOT ask why...) with yesNo both
>>> true
>>> and false. So how can I test the 4 branches in the function calls that I
>>> don't even see and why are there no function calls in the second line
>>> which
>>> is almost identical.
>>>
>>>
>>>
>>> I always thought that branches are only for control structures like if,
>>> ...?
>>>
>>>
>>>
>>> Anybody can help me?
>>>
>>>
>>>
>>> Thank you very much in advance!
>>>
>>>
>>>
>>> Regards,
>>>
>>> Anton
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Cobertura-devel mailing list
>>> Cob...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>>
>>>
>>>
>>>
>>> --
>>> Alejandro Pérez García
>>> Socio fundador de Autentia y www.adictosaltrabajo.com
>>> (Formación, Consultoría, Desarrollo de sistemas transaccionales)
>>> mailto:ale...@au...
>>> Tel.: 655 99 11 75
>>>
>>> Autentia Real Business Solutions S.L.
>>> "Soporte a Desarrollo"
>>> http://www.autentia.com
>>>
>>>
>>>
>>> Este mensaje, y en su caso cualquier fichero anexo al mismo, puede
>>> contener
>>> información confidencial y/o privilegiada, siendo para uso exclusivo del
>>> destinatario. Si Vd. no es el destinatario o lo ha recibido por error,
>>> por
>>> favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente
>>> prohibido por la legislación vigente realizar sin autorización cualquier
>>> copia, revelación o distribución del contenido de este mensaje sin la
>>> autorización expresa del remitente. Las opiniones expresadas en este
>>> correo
>>> son las de su autor y no son, necesariamente, compartidas por Autentia
>>> Real
>>> Business Solutions S.L.
>>>
>>> This e-mail, and in the case of any file annexed to it, may contain
>>> confidential and/or privileged information, and it is exclusively for
>>> the
>>> use of the addresses of the message. If you are not the intended
>>> recipient
>>> (or have received this e-mail in error), please notify the sender
>>> immediately and destroy this e-mail. Any unauthorised copying,
>>> disclosure
>>> or
>>> distribution of the material in this e-mail is strictly forbidden by
>>> current
>>> legislation. The points of view expressed in this e-mail are solely
>>> those
>>> of
>>> the author and may not necessarily be from, or supported by, Autentia
>>> Real
>>> Business Solutions S.L.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Cobertura-devel mailing list
>>> Cob...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>>
>>>
>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>
>
>
>
|
|
From: John W. L. <Joh...@sa...> - 2010-05-21 05:56:33
|
I am confused.
selenium.isTextPresent() is a method that returns a boolean, but it is not a conditional unless it is in an if statement, right? There is only one if statement in this block of code, so the way I see it, there is only one conditional (if (yesNo)).
John
-----Original Message-----
From: Jim Showalter [mailto:ji...@ji...]
Sent: Friday, May 21, 2010 1:46 AM
To: Jake Cobb; John W. Lewis
Cc: cob...@li...; Anton Trapp
Subject: Re: [Cobertura-devel] branch coverage of two function calls???
Okay, I reread the original question, and it's different. Sorry about that.
Anton, for your test to hit all four branches, it has to do this:
1) Make sure text "secure page" is present.
2) Call mustBeAuthenticated with yesNo true.
3) Call mustBeAuthenticated with yesNo false.
4) Make sure text "secure page" is not present.
5) Call mustBeAuthenticated with yesNo true.
6) Call mustBeAuthenticated with yesNo false.
That will cover all four branches.
Does your test do that?
if (yesNo) {
verifyTrue(selenium.isTextPresent("secure page"));
} else {
verifyFalse(selenium.isTextPresent("secure page")); <-- THIS LINE???
}
----- Original Message -----
From: "Jim Showalter" <ji...@ji...>
To: "Jake Cobb" <jak...@ga...>; "John W. Lewis"
<Joh...@sa...>
Cc: <cob...@li...>; "Anton Trapp"
<tm...@al...>
Sent: Thursday, May 20, 2010 10:34 PM
Subject: Re: [Cobertura-devel] branch coverage of two function calls???
> Er, no.
>
> Did anyone read my response to Anton's question?
>
> If you have this structure:
>
> if (cond(foo)) {
> bar
> } else if (!cond(foo)) {
> baz
> }
>
> then it is impossible to make the code take all four possible branches.
>
> Try a truth table with the above example.
>
> Set foo = true. What do you get? You get the first condition true, leading
> to bar
>
> Set foo = false. What do you get? You get the first condition false and
> the second condition true, leading to baz.
>
> You have now gotten 100% statement coverage.
>
> And you have also gotten 100% branch coverage on the first conditional.
>
> But you can never, ever get 100% branch coverage on the second
> conditional, because you can only reach the second conditional if foo is
> false. If foo is true, you'll never get to the second conditional.
>
> Which means you can never get !cond(foo) to evaluate to false, so if it
> gets to the else-if it will never not result in baz.
>
> If you get to the second conditional, you will always get to baz.
> Guaranteed. Thus exactly 50% branch coverage despite 100% statement
> coverage.
>
> Please try this yourself. There is nothing wrong with Cobertura.
>
> ----- Original Message -----
> From: "Jake Cobb" <jak...@ga...>
> To: "John W. Lewis" <Joh...@sa...>
> Cc: <cob...@li...>; "Anton Trapp"
> <tm...@al...>
> Sent: Thursday, May 20, 2010 11:10 AM
> Subject: Re: [Cobertura-devel] branch coverage of two function calls???
>
>
> 2010/5/20 John W. Lewis <Joh...@sa...>
>
>>
>>
>> It definitely looks like there is a problem. The line was exercised
>> twice,
>> so the only reason it would be red is if the branch coverage was not
>> 100%.
>>
>>
>>
>
> It looks like a couple of problems. First, the branch on line 85 is
> definitely covered. It seems to be marked correctly in the code display
> (not red), but the branch coverage overview says no branches are covered.
> If both screenshots are from the same report, the overview should show at
> least 1 branch covered. Anton, can you confirm these screenshots were
> taken
> from the same report instance?
>
> Second, if all branches are attributed to the single method we're shown,
> why
> does it think there is more than one branch in that method?
> Passing/returning a boolean value is not a branch in the bytecode produced
> by the Sun compiler.
>
> e.g. this code...
>
> public void doSomething(boolean yesNo) {
> if( yesNo ) {
> boolTest(getBool());
> } else {
> boolTest2(getBool());
> }
> }
>
> ... produces this bytecode ...
>
> public void doSomething(boolean);
> Code:
> 0: iload_1
> 1: ifeq 15
> 4: aload_0
> 5: aload_0
> 6: invokevirtual #2; //Method getBool:()Z
> 9: invokevirtual #3; //Method boolTest:(Z)V
> 12: goto 23
> 15: aload_0
> 16: aload_0
> 17: invokevirtual #2; //Method getBool:()Z
> 20: invokevirtual #4; //Method boolTest2:(Z)V
> 23: return
>
> ... which has only one branch.
>
>> What version of Java are you using?
>>
>>
>>
>> When you hover over the red line, does the popup say anything?
>>
>>
>>
>> Are there any annotations in the source file?
>>
>>
>>
>> I wonder if the problem can be reproduced with a smaller source file that
>> you can share with us. Or, can you send the corresponding class file?
>> Or,
>> use a decompiler such as Jad and show us the decompiled source?
>>
>>
>>
>> John
>>
>>
>>
>
> Anton,
>
> In addition to John's questions above, are you using any other
> bytecode-modifying processing (e.g. AspectJ)? Are you using a compiler
> other than Sun's?
>
> -Jake
>
>
>> *From:* Anton Trapp [mailto:tm...@al...]
>> *Sent:* Thursday, May 20, 2010 9:59 AM
>> *To:* cob...@li...
>> *Subject:* Re: [Cobertura-devel] branch coverage of two function calls???
>>
>>
>>
>> Hi!
>>
>>
>>
>> Thank you for your fast answer! As I said, I do run tests with true/false
>> and the if statement is not even mentioned in the branches:
>>
>>
>>
>> Overview:
>>
>>
>>
>>
>>
>> code:
>>
>>
>>
>>
>>
>> So yes/No is working, but line 88 has line coverage but no branch
>> coverage.
>> I am understanding my question, but I don't understand what cobertura
>> needs
>> to branch in line 88 where there is not even a control structure...
>>
>>
>>
>> Regards,
>>
>> Anton
>>
>>
>>
>> Am 20.05.2010 um 15:39 schrieb Alejandro Pérez García:
>>
>>
>>
>> Hi
>>
>> I'm sorry, but I thikn that I don't understand your question.
>>
>> If you want to cover the "else" sentence (the sentence you marked with
>> "THIS LINE") you only have to do "false" the yesNo expresion.
>>
>> I don't understand where is the problem.
>>
>> Regards
>>
>>
>>
>> 2010/5/20 Anton Trapp <tm...@al...>
>>
>> Hi!
>>
>>
>>
>> How can I cover the 4 branches of:
>>
>>
>>
>> if (yesNo) {
>>
>> verifyTrue(selenium.isTextPresent("secure page"));
>>
>> } else {
>>
>> verifyFalse(selenium.isTextPresent("secure page")); <-- THIS
>> LINE???
>>
>> }
>>
>>
>>
>> Code coverage is 100%, this test is called multiple times (yes I do
>> perform
>> a code coverage of the tests, please do NOT ask why...) with yesNo both
>> true
>> and false. So how can I test the 4 branches in the function calls that I
>> don't even see and why are there no function calls in the second line
>> which
>> is almost identical.
>>
>>
>>
>> I always thought that branches are only for control structures like if,
>> ...?
>>
>>
>>
>> Anybody can help me?
>>
>>
>>
>> Thank you very much in advance!
>>
>>
>>
>> Regards,
>>
>> Anton
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Cobertura-devel mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>
>>
>>
>>
>> --
>> Alejandro Pérez García
>> Socio fundador de Autentia y www.adictosaltrabajo.com
>> (Formación, Consultoría, Desarrollo de sistemas transaccionales)
>> mailto:ale...@au...
>> Tel.: 655 99 11 75
>>
>> Autentia Real Business Solutions S.L.
>> "Soporte a Desarrollo"
>> http://www.autentia.com
>>
>>
>>
>> Este mensaje, y en su caso cualquier fichero anexo al mismo, puede
>> contener
>> información confidencial y/o privilegiada, siendo para uso exclusivo del
>> destinatario. Si Vd. no es el destinatario o lo ha recibido por error,
>> por
>> favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente
>> prohibido por la legislación vigente realizar sin autorización cualquier
>> copia, revelación o distribución del contenido de este mensaje sin la
>> autorización expresa del remitente. Las opiniones expresadas en este
>> correo
>> son las de su autor y no son, necesariamente, compartidas por Autentia
>> Real
>> Business Solutions S.L.
>>
>> This e-mail, and in the case of any file annexed to it, may contain
>> confidential and/or privileged information, and it is exclusively for the
>> use of the addresses of the message. If you are not the intended
>> recipient
>> (or have received this e-mail in error), please notify the sender
>> immediately and destroy this e-mail. Any unauthorised copying, disclosure
>> or
>> distribution of the material in this e-mail is strictly forbidden by
>> current
>> legislation. The points of view expressed in this e-mail are solely those
>> of
>> the author and may not necessarily be from, or supported by, Autentia
>> Real
>> Business Solutions S.L.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Cobertura-devel mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>
>>
>
>
>
> --------------------------------------------------------------------------------
>
>
>> ------------------------------------------------------------------------------
>>
>>
>
|
|
From: Jim S. <ji...@ji...> - 2010-05-21 05:45:44
|
Okay, I reread the original question, and it's different. Sorry about that.
Anton, for your test to hit all four branches, it has to do this:
1) Make sure text "secure page" is present.
2) Call mustBeAuthenticated with yesNo true.
3) Call mustBeAuthenticated with yesNo false.
4) Make sure text "secure page" is not present.
5) Call mustBeAuthenticated with yesNo true.
6) Call mustBeAuthenticated with yesNo false.
That will cover all four branches.
Does your test do that?
if (yesNo) {
verifyTrue(selenium.isTextPresent("secure page"));
} else {
verifyFalse(selenium.isTextPresent("secure page")); <-- THIS LINE???
}
----- Original Message -----
From: "Jim Showalter" <ji...@ji...>
To: "Jake Cobb" <jak...@ga...>; "John W. Lewis"
<Joh...@sa...>
Cc: <cob...@li...>; "Anton Trapp"
<tm...@al...>
Sent: Thursday, May 20, 2010 10:34 PM
Subject: Re: [Cobertura-devel] branch coverage of two function calls???
> Er, no.
>
> Did anyone read my response to Anton's question?
>
> If you have this structure:
>
> if (cond(foo)) {
> bar
> } else if (!cond(foo)) {
> baz
> }
>
> then it is impossible to make the code take all four possible branches.
>
> Try a truth table with the above example.
>
> Set foo = true. What do you get? You get the first condition true, leading
> to bar
>
> Set foo = false. What do you get? You get the first condition false and
> the second condition true, leading to baz.
>
> You have now gotten 100% statement coverage.
>
> And you have also gotten 100% branch coverage on the first conditional.
>
> But you can never, ever get 100% branch coverage on the second
> conditional, because you can only reach the second conditional if foo is
> false. If foo is true, you'll never get to the second conditional.
>
> Which means you can never get !cond(foo) to evaluate to false, so if it
> gets to the else-if it will never not result in baz.
>
> If you get to the second conditional, you will always get to baz.
> Guaranteed. Thus exactly 50% branch coverage despite 100% statement
> coverage.
>
> Please try this yourself. There is nothing wrong with Cobertura.
>
> ----- Original Message -----
> From: "Jake Cobb" <jak...@ga...>
> To: "John W. Lewis" <Joh...@sa...>
> Cc: <cob...@li...>; "Anton Trapp"
> <tm...@al...>
> Sent: Thursday, May 20, 2010 11:10 AM
> Subject: Re: [Cobertura-devel] branch coverage of two function calls???
>
>
> 2010/5/20 John W. Lewis <Joh...@sa...>
>
>>
>>
>> It definitely looks like there is a problem. The line was exercised
>> twice,
>> so the only reason it would be red is if the branch coverage was not
>> 100%.
>>
>>
>>
>
> It looks like a couple of problems. First, the branch on line 85 is
> definitely covered. It seems to be marked correctly in the code display
> (not red), but the branch coverage overview says no branches are covered.
> If both screenshots are from the same report, the overview should show at
> least 1 branch covered. Anton, can you confirm these screenshots were
> taken
> from the same report instance?
>
> Second, if all branches are attributed to the single method we're shown,
> why
> does it think there is more than one branch in that method?
> Passing/returning a boolean value is not a branch in the bytecode produced
> by the Sun compiler.
>
> e.g. this code...
>
> public void doSomething(boolean yesNo) {
> if( yesNo ) {
> boolTest(getBool());
> } else {
> boolTest2(getBool());
> }
> }
>
> ... produces this bytecode ...
>
> public void doSomething(boolean);
> Code:
> 0: iload_1
> 1: ifeq 15
> 4: aload_0
> 5: aload_0
> 6: invokevirtual #2; //Method getBool:()Z
> 9: invokevirtual #3; //Method boolTest:(Z)V
> 12: goto 23
> 15: aload_0
> 16: aload_0
> 17: invokevirtual #2; //Method getBool:()Z
> 20: invokevirtual #4; //Method boolTest2:(Z)V
> 23: return
>
> ... which has only one branch.
>
>> What version of Java are you using?
>>
>>
>>
>> When you hover over the red line, does the popup say anything?
>>
>>
>>
>> Are there any annotations in the source file?
>>
>>
>>
>> I wonder if the problem can be reproduced with a smaller source file that
>> you can share with us. Or, can you send the corresponding class file?
>> Or,
>> use a decompiler such as Jad and show us the decompiled source?
>>
>>
>>
>> John
>>
>>
>>
>
> Anton,
>
> In addition to John's questions above, are you using any other
> bytecode-modifying processing (e.g. AspectJ)? Are you using a compiler
> other than Sun's?
>
> -Jake
>
>
>> *From:* Anton Trapp [mailto:tm...@al...]
>> *Sent:* Thursday, May 20, 2010 9:59 AM
>> *To:* cob...@li...
>> *Subject:* Re: [Cobertura-devel] branch coverage of two function calls???
>>
>>
>>
>> Hi!
>>
>>
>>
>> Thank you for your fast answer! As I said, I do run tests with true/false
>> and the if statement is not even mentioned in the branches:
>>
>>
>>
>> Overview:
>>
>>
>>
>>
>>
>> code:
>>
>>
>>
>>
>>
>> So yes/No is working, but line 88 has line coverage but no branch
>> coverage.
>> I am understanding my question, but I don't understand what cobertura
>> needs
>> to branch in line 88 where there is not even a control structure...
>>
>>
>>
>> Regards,
>>
>> Anton
>>
>>
>>
>> Am 20.05.2010 um 15:39 schrieb Alejandro Pérez García:
>>
>>
>>
>> Hi
>>
>> I'm sorry, but I thikn that I don't understand your question.
>>
>> If you want to cover the "else" sentence (the sentence you marked with
>> "THIS LINE") you only have to do "false" the yesNo expresion.
>>
>> I don't understand where is the problem.
>>
>> Regards
>>
>>
>>
>> 2010/5/20 Anton Trapp <tm...@al...>
>>
>> Hi!
>>
>>
>>
>> How can I cover the 4 branches of:
>>
>>
>>
>> if (yesNo) {
>>
>> verifyTrue(selenium.isTextPresent("secure page"));
>>
>> } else {
>>
>> verifyFalse(selenium.isTextPresent("secure page")); <-- THIS
>> LINE???
>>
>> }
>>
>>
>>
>> Code coverage is 100%, this test is called multiple times (yes I do
>> perform
>> a code coverage of the tests, please do NOT ask why...) with yesNo both
>> true
>> and false. So how can I test the 4 branches in the function calls that I
>> don't even see and why are there no function calls in the second line
>> which
>> is almost identical.
>>
>>
>>
>> I always thought that branches are only for control structures like if,
>> ...?
>>
>>
>>
>> Anybody can help me?
>>
>>
>>
>> Thank you very much in advance!
>>
>>
>>
>> Regards,
>>
>> Anton
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Cobertura-devel mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>
>>
>>
>>
>> --
>> Alejandro Pérez García
>> Socio fundador de Autentia y www.adictosaltrabajo.com
>> (Formación, Consultoría, Desarrollo de sistemas transaccionales)
>> mailto:ale...@au...
>> Tel.: 655 99 11 75
>>
>> Autentia Real Business Solutions S.L.
>> "Soporte a Desarrollo"
>> http://www.autentia.com
>>
>>
>>
>> Este mensaje, y en su caso cualquier fichero anexo al mismo, puede
>> contener
>> información confidencial y/o privilegiada, siendo para uso exclusivo del
>> destinatario. Si Vd. no es el destinatario o lo ha recibido por error,
>> por
>> favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente
>> prohibido por la legislación vigente realizar sin autorización cualquier
>> copia, revelación o distribución del contenido de este mensaje sin la
>> autorización expresa del remitente. Las opiniones expresadas en este
>> correo
>> son las de su autor y no son, necesariamente, compartidas por Autentia
>> Real
>> Business Solutions S.L.
>>
>> This e-mail, and in the case of any file annexed to it, may contain
>> confidential and/or privileged information, and it is exclusively for the
>> use of the addresses of the message. If you are not the intended
>> recipient
>> (or have received this e-mail in error), please notify the sender
>> immediately and destroy this e-mail. Any unauthorised copying, disclosure
>> or
>> distribution of the material in this e-mail is strictly forbidden by
>> current
>> legislation. The points of view expressed in this e-mail are solely those
>> of
>> the author and may not necessarily be from, or supported by, Autentia
>> Real
>> Business Solutions S.L.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Cobertura-devel mailing list
>> Cob...@li...
>> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>>
>>
>
>
>
> --------------------------------------------------------------------------------
>
>
>> ------------------------------------------------------------------------------
>>
>>
>
|
|
From: Jim S. <ji...@ji...> - 2010-05-21 05:34:13
|
Er, no.
Did anyone read my response to Anton's question?
If you have this structure:
if (cond(foo)) {
bar
} else if (!cond(foo)) {
baz
}
then it is impossible to make the code take all four possible branches.
Try a truth table with the above example.
Set foo = true. What do you get? You get the first condition true, leading
to bar
Set foo = false. What do you get? You get the first condition false and the
second condition true, leading to baz.
You have now gotten 100% statement coverage.
And you have also gotten 100% branch coverage on the first conditional.
But you can never, ever get 100% branch coverage on the second conditional,
because you can only reach the second conditional if foo is false. If foo is
true, you'll never get to the second conditional.
Which means you can never get !cond(foo) to evaluate to false, so if it gets
to the else-if it will never not result in baz.
If you get to the second conditional, you will always get to baz.
Guaranteed. Thus exactly 50% branch coverage despite 100% statement
coverage.
Please try this yourself. There is nothing wrong with Cobertura.
----- Original Message -----
From: "Jake Cobb" <jak...@ga...>
To: "John W. Lewis" <Joh...@sa...>
Cc: <cob...@li...>; "Anton Trapp"
<tm...@al...>
Sent: Thursday, May 20, 2010 11:10 AM
Subject: Re: [Cobertura-devel] branch coverage of two function calls???
2010/5/20 John W. Lewis <Joh...@sa...>
>
>
> It definitely looks like there is a problem. The line was exercised
> twice,
> so the only reason it would be red is if the branch coverage was not 100%.
>
>
>
It looks like a couple of problems. First, the branch on line 85 is
definitely covered. It seems to be marked correctly in the code display
(not red), but the branch coverage overview says no branches are covered.
If both screenshots are from the same report, the overview should show at
least 1 branch covered. Anton, can you confirm these screenshots were taken
from the same report instance?
Second, if all branches are attributed to the single method we're shown, why
does it think there is more than one branch in that method?
Passing/returning a boolean value is not a branch in the bytecode produced
by the Sun compiler.
e.g. this code...
public void doSomething(boolean yesNo) {
if( yesNo ) {
boolTest(getBool());
} else {
boolTest2(getBool());
}
}
... produces this bytecode ...
public void doSomething(boolean);
Code:
0: iload_1
1: ifeq 15
4: aload_0
5: aload_0
6: invokevirtual #2; //Method getBool:()Z
9: invokevirtual #3; //Method boolTest:(Z)V
12: goto 23
15: aload_0
16: aload_0
17: invokevirtual #2; //Method getBool:()Z
20: invokevirtual #4; //Method boolTest2:(Z)V
23: return
... which has only one branch.
> What version of Java are you using?
>
>
>
> When you hover over the red line, does the popup say anything?
>
>
>
> Are there any annotations in the source file?
>
>
>
> I wonder if the problem can be reproduced with a smaller source file that
> you can share with us. Or, can you send the corresponding class file?
> Or,
> use a decompiler such as Jad and show us the decompiled source?
>
>
>
> John
>
>
>
Anton,
In addition to John's questions above, are you using any other
bytecode-modifying processing (e.g. AspectJ)? Are you using a compiler
other than Sun's?
-Jake
> *From:* Anton Trapp [mailto:tm...@al...]
> *Sent:* Thursday, May 20, 2010 9:59 AM
> *To:* cob...@li...
> *Subject:* Re: [Cobertura-devel] branch coverage of two function calls???
>
>
>
> Hi!
>
>
>
> Thank you for your fast answer! As I said, I do run tests with true/false
> and the if statement is not even mentioned in the branches:
>
>
>
> Overview:
>
>
>
>
>
> code:
>
>
>
>
>
> So yes/No is working, but line 88 has line coverage but no branch
> coverage.
> I am understanding my question, but I don't understand what cobertura
> needs
> to branch in line 88 where there is not even a control structure...
>
>
>
> Regards,
>
> Anton
>
>
>
> Am 20.05.2010 um 15:39 schrieb Alejandro Pérez García:
>
>
>
> Hi
>
> I'm sorry, but I thikn that I don't understand your question.
>
> If you want to cover the "else" sentence (the sentence you marked with
> "THIS LINE") you only have to do "false" the yesNo expresion.
>
> I don't understand where is the problem.
>
> Regards
>
>
>
> 2010/5/20 Anton Trapp <tm...@al...>
>
> Hi!
>
>
>
> How can I cover the 4 branches of:
>
>
>
> if (yesNo) {
>
> verifyTrue(selenium.isTextPresent("secure page"));
>
> } else {
>
> verifyFalse(selenium.isTextPresent("secure page")); <-- THIS
> LINE???
>
> }
>
>
>
> Code coverage is 100%, this test is called multiple times (yes I do
> perform
> a code coverage of the tests, please do NOT ask why...) with yesNo both
> true
> and false. So how can I test the 4 branches in the function calls that I
> don't even see and why are there no function calls in the second line
> which
> is almost identical.
>
>
>
> I always thought that branches are only for control structures like if,
> ...?
>
>
>
> Anybody can help me?
>
>
>
> Thank you very much in advance!
>
>
>
> Regards,
>
> Anton
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
>
>
> --
> Alejandro Pérez García
> Socio fundador de Autentia y www.adictosaltrabajo.com
> (Formación, Consultoría, Desarrollo de sistemas transaccionales)
> mailto:ale...@au...
> Tel.: 655 99 11 75
>
> Autentia Real Business Solutions S.L.
> "Soporte a Desarrollo"
> http://www.autentia.com
>
>
>
> Este mensaje, y en su caso cualquier fichero anexo al mismo, puede
> contener
> información confidencial y/o privilegiada, siendo para uso exclusivo del
> destinatario. Si Vd. no es el destinatario o lo ha recibido por error, por
> favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente
> prohibido por la legislación vigente realizar sin autorización cualquier
> copia, revelación o distribución del contenido de este mensaje sin la
> autorización expresa del remitente. Las opiniones expresadas en este
> correo
> son las de su autor y no son, necesariamente, compartidas por Autentia
> Real
> Business Solutions S.L.
>
> This e-mail, and in the case of any file annexed to it, may contain
> confidential and/or privileged information, and it is exclusively for the
> use of the addresses of the message. If you are not the intended recipient
> (or have received this e-mail in error), please notify the sender
> immediately and destroy this e-mail. Any unauthorised copying, disclosure
> or
> distribution of the material in this e-mail is strictly forbidden by
> current
> legislation. The points of view expressed in this e-mail are solely those
> of
> the author and may not necessarily be from, or supported by, Autentia Real
> Business Solutions S.L.
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
--------------------------------------------------------------------------------
> ------------------------------------------------------------------------------
>
>
|
|
From: Richard A. <ric...@go...> - 2010-05-20 22:21:15
|
Hi Just getting started with Cobertura. A few questions centered around --ignore and --ignoreBranches: 1. The description of the --ignore option for cobertura-instrument.bat is: Description: "Specify a regular expression to filter out certain lines of your source code. This is useful for ignoring logging statements. You can have as many --ignore statements as you want" Default value: "no files are ignored" Can --ignore really specify lines of source code? Or is it limited to specifying classes, as in the example given (--ignore "org.apache.log4j.*") 2. In instrument.Main.java and in ant.InstrumentTask.java, there is processing for --ignoreBranches and <ignoreBranches regex=... />, but I can't find any related documentation. How do we use regexs to specify branches in this case? 3. I was going to ask what the difference is between using --ignore and --ignoreBranches versus excluding a class. But if --ignore and --ignoreBranches can get down to line and branch level, I guess I have my answer. Richard |
|
From: John W. L. <Joh...@sa...> - 2010-05-20 20:57:44
|
No. But, it looks like Joachim Hofer is working on one: http://github.com/jmhofer/eCobertura John From: Yerukala, Chandra (US - Austin) [mailto:cye...@de...] Sent: Thursday, May 20, 2010 4:55 PM To: John W. Lewis; cobertura-devel Subject: RE: [Cobertura-devel] FW: cobertura Hi John, Thank you so much. It would be nice if you could respond to one more question. Do you have Eclipse? If not is it on the way? Best Regards, Chandra Yerukala T&PM | Public Sector Deloitte Consulting LLP 400 W. 15th Street, Austin TX 78701 | United States Tel/Direct 512 691 2198 | Mobile 602 770 0603 | Fax 512 480 1318 cye...@de... | www.deloitte.com P Please consider the environment before printing. From: John W. Lewis [mailto:Joh...@sa...] Sent: Wednesday, May 19, 2010 9:09 PM To: jth...@us...; Yerukala, Chandra (US - Austin); cobertura-devel Subject: RE: [Cobertura-devel] FW: cobertura 1.8 works with Java 1.4. From: Jeremy Thomerson [mailto:jth...@us...] Sent: Wednesday, May 19, 2010 9:28 PM To: Yerukala, Chandra (US - Austin); cobertura-devel Subject: Re: [Cobertura-devel] FW: cobertura I actually don't know - I have been inactive on Cobertura for quite a while. Someone from the list should be able to help. Jeremy On Wed, May 19, 2010 at 5:33 PM, Yerukala, Chandra (US - Austin) <cye...@de...<mailto:cye...@de...>> wrote: Best Regards, Chandra Yerukala T&PM | Public Sector Deloitte Consulting LLP 400 W. 15th Street, Austin TX 78701 | United States Tel/Direct 512 691 2198 | Mobile 602 770 0603 | Fax 512 480 1318 cye...@de...<mailto:cye...@de...> | www.deloitte.com<http://www.deloitte.com> P Please consider the environment before printing. From: Yerukala, Chandra (US - Austin) Sent: Wednesday, May 19, 2010 5:29 PM To: 'cob...@li...<mailto:cob...@li...>' Subject: cobertura Hello, Thank you for great work you are doing for the java community. We need your help; we have JDK 1.4 application, could you please tell which version of cobertura would help us? Cobertura 1.9 runs only on JDK1.5 or newer, I need Cobertura version to work on JDK 1.4 Best Regards, Chandra Yerukala T&PM | Public Sector Deloitte Consulting LLP 400 W. 15th Street, Austin TX 78701 | United States Tel/Direct 512 691 2198 | Mobile 602 770 0603 | Fax 512 480 1318 cye...@de...<mailto:cye...@de...> | www.deloitte.com<http://www.deloitte.com> P Please consider the environment before printing. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] |
|
From: Jake C. <jak...@ga...> - 2010-05-20 18:10:43
|
2010/5/20 John W. Lewis <Joh...@sa...>
>
>
> It definitely looks like there is a problem. The line was exercised twice,
> so the only reason it would be red is if the branch coverage was not 100%.
>
>
>
It looks like a couple of problems. First, the branch on line 85 is
definitely covered. It seems to be marked correctly in the code display
(not red), but the branch coverage overview says no branches are covered.
If both screenshots are from the same report, the overview should show at
least 1 branch covered. Anton, can you confirm these screenshots were taken
from the same report instance?
Second, if all branches are attributed to the single method we're shown, why
does it think there is more than one branch in that method?
Passing/returning a boolean value is not a branch in the bytecode produced
by the Sun compiler.
e.g. this code...
public void doSomething(boolean yesNo) {
if( yesNo ) {
boolTest(getBool());
} else {
boolTest2(getBool());
}
}
... produces this bytecode ...
public void doSomething(boolean);
Code:
0: iload_1
1: ifeq 15
4: aload_0
5: aload_0
6: invokevirtual #2; //Method getBool:()Z
9: invokevirtual #3; //Method boolTest:(Z)V
12: goto 23
15: aload_0
16: aload_0
17: invokevirtual #2; //Method getBool:()Z
20: invokevirtual #4; //Method boolTest2:(Z)V
23: return
... which has only one branch.
> What version of Java are you using?
>
>
>
> When you hover over the red line, does the popup say anything?
>
>
>
> Are there any annotations in the source file?
>
>
>
> I wonder if the problem can be reproduced with a smaller source file that
> you can share with us. Or, can you send the corresponding class file? Or,
> use a decompiler such as Jad and show us the decompiled source?
>
>
>
> John
>
>
>
Anton,
In addition to John's questions above, are you using any other
bytecode-modifying processing (e.g. AspectJ)? Are you using a compiler
other than Sun's?
-Jake
> *From:* Anton Trapp [mailto:tm...@al...]
> *Sent:* Thursday, May 20, 2010 9:59 AM
> *To:* cob...@li...
> *Subject:* Re: [Cobertura-devel] branch coverage of two function calls???
>
>
>
> Hi!
>
>
>
> Thank you for your fast answer! As I said, I do run tests with true/false
> and the if statement is not even mentioned in the branches:
>
>
>
> Overview:
>
>
>
>
>
> code:
>
>
>
>
>
> So yes/No is working, but line 88 has line coverage but no branch coverage.
> I am understanding my question, but I don't understand what cobertura needs
> to branch in line 88 where there is not even a control structure...
>
>
>
> Regards,
>
> Anton
>
>
>
> Am 20.05.2010 um 15:39 schrieb Alejandro Pérez García:
>
>
>
> Hi
>
> I'm sorry, but I thikn that I don't understand your question.
>
> If you want to cover the "else" sentence (the sentence you marked with
> "THIS LINE") you only have to do "false" the yesNo expresion.
>
> I don't understand where is the problem.
>
> Regards
>
>
>
> 2010/5/20 Anton Trapp <tm...@al...>
>
> Hi!
>
>
>
> How can I cover the 4 branches of:
>
>
>
> if (yesNo) {
>
> verifyTrue(selenium.isTextPresent("secure page"));
>
> } else {
>
> verifyFalse(selenium.isTextPresent("secure page")); <-- THIS
> LINE???
>
> }
>
>
>
> Code coverage is 100%, this test is called multiple times (yes I do perform
> a code coverage of the tests, please do NOT ask why...) with yesNo both true
> and false. So how can I test the 4 branches in the function calls that I
> don't even see and why are there no function calls in the second line which
> is almost identical.
>
>
>
> I always thought that branches are only for control structures like if,
> ...?
>
>
>
> Anybody can help me?
>
>
>
> Thank you very much in advance!
>
>
>
> Regards,
>
> Anton
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
>
>
> --
> Alejandro Pérez García
> Socio fundador de Autentia y www.adictosaltrabajo.com
> (Formación, Consultoría, Desarrollo de sistemas transaccionales)
> mailto:ale...@au...
> Tel.: 655 99 11 75
>
> Autentia Real Business Solutions S.L.
> "Soporte a Desarrollo"
> http://www.autentia.com
>
>
>
> Este mensaje, y en su caso cualquier fichero anexo al mismo, puede contener
> información confidencial y/o privilegiada, siendo para uso exclusivo del
> destinatario. Si Vd. no es el destinatario o lo ha recibido por error, por
> favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente
> prohibido por la legislación vigente realizar sin autorización cualquier
> copia, revelación o distribución del contenido de este mensaje sin la
> autorización expresa del remitente. Las opiniones expresadas en este correo
> son las de su autor y no son, necesariamente, compartidas por Autentia Real
> Business Solutions S.L.
>
> This e-mail, and in the case of any file annexed to it, may contain
> confidential and/or privileged information, and it is exclusively for the
> use of the addresses of the message. If you are not the intended recipient
> (or have received this e-mail in error), please notify the sender
> immediately and destroy this e-mail. Any unauthorised copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden by current
> legislation. The points of view expressed in this e-mail are solely those of
> the author and may not necessarily be from, or supported by, Autentia Real
> Business Solutions S.L.
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
|
|
From: Jake C. <jak...@ga...> - 2010-05-20 17:57:50
|
How many branches does it say are in the file with this version? What Java
compiler are you using?
-Jake
2010/5/20 Anton Trapp <tm...@al...>
> Thanks!
>
> So the solution is something like (avoid if / else) *g*:
>
> protected void mustBeAuthenticated(boolean yesNo) {
> open("/BIG/secure.do");
> waitForPageToLoad();
> verifyFalse(selenium.isTextPresent("secure page") ^ yesNo);
> }
>
> which works fine :)
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>
|
|
From: Anton T. <tm...@al...> - 2010-05-20 17:03:15
|
Thanks!
So the solution is something like (avoid if / else) *g*:
protected void mustBeAuthenticated(boolean yesNo) {
open("/BIG/secure.do");
waitForPageToLoad();
verifyFalse(selenium.isTextPresent("secure page") ^ yesNo);
}
which works fine :)
|
89 messages has been excluded from this view by a project administrator.
