cobertura-featurerequests — Automated emails from our feature request tracking system

[ cobertura-Feature Requests-2034991 ] no checking report for maven2 ?

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

Feature Requests item #2034991, was opened at 2008-08-01 14:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2034991&group_id=130558

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

Initial Comment:
It seems that the cobertura plugin for maven1 has 2 kinds of reports (the normal coverage report and a check-report).
Unfortunately, the plugin for maven2 doesn't seem to generate the checking report (or am i missing something?)

Thanks !

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 11:01
Message generated for change (Comment added) made by andipak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558

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

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:50

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

As opposed to the posted snippet I'm directly replacing the plugin .jar's
by the instrumented ones. And I can reproduce the problem why just
executing the java command on the commandline. So it seems eclipse is
somehow not loading the cobertura and related jar's. 

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

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:42

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

Missed that sourceforge wouldn't ask me for login before sending the
comment. So that last one was from me.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-07-30 17:41

Message:
Logged In: NO 

I'm having the same problem, even adding cobertura.jar along with the asm,
jakarta and log4j jars to the ext/ dir and using that bootloader doesn't
seem to help here.

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

Comment By: nchaitas (nchaitas)
Date: 2008-07-30 17:29

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

Hi!
One more piece of information that might be useful.
Cobertura gets executed through use of the <junit> Ant task (according to
its instructions), while Eclipse automated tests get executed through the
<java> Ant task (also with fork="true" and , which accept the Ant elements
<jvmarg>, <sysproperty> and <classpath>, which I used to specify the type
of the class loader, the location of the cobertura.ser and of my
instrumented classes respectively. In particular the invocation of this
<java> task looked like this (in my very first attempt):
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
    		  	<fileset dir="${eclipse-home}/plugins">
            	<include name="org.eclipse.equinox.launcher_*.jar"/>
          	</fileset>
	        </classpath>
		    <arg line="-application ${application}"/>
		    <arg line="-data ${data-dir}"/>
		    <arg line="formatter=${formatter},${test-output}"/>
		    <arg line="-testPluginName ${plugin-name}"/>
		    <arg line="-className ${classname}"/>
		    <arg line="-os ${os}"/>
		    <arg line="-ws ${ws}"/>
		    <arg line="-arch ${arch}"/>
		    <arg line="-consolelog"/>
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		    <sysproperty key="PLUGIN_PATH" value="${plugin-path}"/> 
			 	<!-- Define cobertura specific elements -->
				<sysproperty key="net.sourceforge.cobertura.datafile"
file="${coberturaScripts}/cobertura.ser" />
		    <classpath>
		      <fileset dir="${instrumented}">
		        <include name="**/*.jar"/>
		      </fileset>
		      <fileset dir="${jars}">
		        <include name="**/*.jar"/>
		      </fileset>
	    	</classpath>
				<classpath refid="cobertura.classpath" />
		</java>

As long as I don't instrument my classes and I don't define any cobertura
specific elements in this <java> task my tests run normally.
When I instrument my classes and I use the <junit> task as described in
the cobertura instructions then (after getting an output of many exceptions
on the console upon initialization) only some of my tests get executed, I
assume these are the ones that can get executed as junit tests as well as
junit (Eclipse) plugin tests.

I hope that something of all these could be useful... :o)
Regards,
neo

PS: By the way -even if this does not actually belong to this discussion-,
I had problems with the <cobertura-report> task, particularly with defining
the set of the source files of my multiple eclipse plugin-projects. This
problem is documented very good here
(https://sourceforge.net/mailarchive/forum.php?thread_name=780385.62813.qm%40web56601.mail.re3.yahoo.com&forum_name=cobertura-devel)
by another user and the solution proposed there (namely the use of groovy
ant task) did work for me, indeed! However, I believe that allowing the Ant
element <dirset> to <cobertura-report> task would be the clean solution for
defining multiple source packages. In my opinion a feature request upon
that too is not such a bad idea, since the use of the <cobertura-merge>
task to merge multiple coverage data files is not so convenient.


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

Comment By: nchaitas (nchaitas)
Date: 2008-07-29 13:55

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

Hi John,

thanks for your response.
Unfortunately I am not familiar with the way the code coverage tools
instrument the classes, but it seems that you do, so I appreciate a
lot your assistance!

The EMMA link you mentioned is:
http://emma.sourceforge.net/userguide/ar01s02s03.html (for command line)
and
http://emma.sourceforge.net/userguide/ar01s03s03.html (for ANT)

The in-place instrumentation is not the reason it doesn't work, since
I manually replace the original classes with the instrumented ones.

In Eclipse there are 4 ways to define the classloader type (s.
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04389.html).
EMMA works for eclipse, when it gets installed on the ext/ directory
of the JRE and the Eclipse classloader type is set to "ext" (however
EMMA's got just one jar, while cobertura.jar depends on 4 other jars).
I tried putting cobertura.jar on the JRE/ext directory and setting the
Eclipse classloader type to "ext" and it didn't work.
My classes could still not find
cobertura.jar\net\sourceforge\cobertura\coveragedata\HasBeenInstrumented.class.

I also tried for instance to create an Eclipse cobertura plugin (a wrapper

of cobertura.jar and its 4 required jars under lib/), add it as a
dependency 
to my plugins and then integrate it to my build process (without any
references 
to it of course). While in the Eclipse IDE my plugins set to depend on my
new 
cobertura plugin could reference class coveragedata\HasBeenInstrumented
the 
generated byte code instrumented into my plugins in the scope of the
testing 
process still did not work.

I read somewhere that EMMA and cobertura generate pretty different
instrumented byte codes, so I just guessed, that the way the generated 
byte code references the cobertura classes was the problem.
For this reason and because it seems I was not the only one who tried
to integrate cobertura to Eclipse PDE (Plugin Development Environment)
I posted this issue under feature requests and not as a bug.

I hope that that could clear up things a little bit.
Kind regards,
neo

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

Comment By: John Lewis (lewijw)
Date: 2008-07-28 14:22

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

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 11:01
Message generated for change (Comment added) made by andipak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558

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

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:42

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

Missed that sourceforge wouldn't ask me for login before sending the
comment. So that last one was from me.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-07-30 17:41

Message:
Logged In: NO 

I'm having the same problem, even adding cobertura.jar along with the asm,
jakarta and log4j jars to the ext/ dir and using that bootloader doesn't
seem to help here.

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

Comment By: nchaitas (nchaitas)
Date: 2008-07-30 17:29

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

Hi!
One more piece of information that might be useful.
Cobertura gets executed through use of the <junit> Ant task (according to
its instructions), while Eclipse automated tests get executed through the
<java> Ant task (also with fork="true" and , which accept the Ant elements
<jvmarg>, <sysproperty> and <classpath>, which I used to specify the type
of the class loader, the location of the cobertura.ser and of my
instrumented classes respectively. In particular the invocation of this
<java> task looked like this (in my very first attempt):
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
    		  	<fileset dir="${eclipse-home}/plugins">
            	<include name="org.eclipse.equinox.launcher_*.jar"/>
          	</fileset>
	        </classpath>
		    <arg line="-application ${application}"/>
		    <arg line="-data ${data-dir}"/>
		    <arg line="formatter=${formatter},${test-output}"/>
		    <arg line="-testPluginName ${plugin-name}"/>
		    <arg line="-className ${classname}"/>
		    <arg line="-os ${os}"/>
		    <arg line="-ws ${ws}"/>
		    <arg line="-arch ${arch}"/>
		    <arg line="-consolelog"/>
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		    <sysproperty key="PLUGIN_PATH" value="${plugin-path}"/> 
			 	<!-- Define cobertura specific elements -->
				<sysproperty key="net.sourceforge.cobertura.datafile"
file="${coberturaScripts}/cobertura.ser" />
		    <classpath>
		      <fileset dir="${instrumented}">
		        <include name="**/*.jar"/>
		      </fileset>
		      <fileset dir="${jars}">
		        <include name="**/*.jar"/>
		      </fileset>
	    	</classpath>
				<classpath refid="cobertura.classpath" />
		</java>

As long as I don't instrument my classes and I don't define any cobertura
specific elements in this <java> task my tests run normally.
When I instrument my classes and I use the <junit> task as described in
the cobertura instructions then (after getting an output of many exceptions
on the console upon initialization) only some of my tests get executed, I
assume these are the ones that can get executed as junit tests as well as
junit (Eclipse) plugin tests.

I hope that something of all these could be useful... :o)
Regards,
neo

PS: By the way -even if this does not actually belong to this discussion-,
I had problems with the <cobertura-report> task, particularly with defining
the set of the source files of my multiple eclipse plugin-projects. This
problem is documented very good here
(https://sourceforge.net/mailarchive/forum.php?thread_name=780385.62813.qm%40web56601.mail.re3.yahoo.com&forum_name=cobertura-devel)
by another user and the solution proposed there (namely the use of groovy
ant task) did work for me, indeed! However, I believe that allowing the Ant
element <dirset> to <cobertura-report> task would be the clean solution for
defining multiple source packages. In my opinion a feature request upon
that too is not such a bad idea, since the use of the <cobertura-merge>
task to merge multiple coverage data files is not so convenient.


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

Comment By: nchaitas (nchaitas)
Date: 2008-07-29 13:55

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

Hi John,

thanks for your response.
Unfortunately I am not familiar with the way the code coverage tools
instrument the classes, but it seems that you do, so I appreciate a
lot your assistance!

The EMMA link you mentioned is:
http://emma.sourceforge.net/userguide/ar01s02s03.html (for command line)
and
http://emma.sourceforge.net/userguide/ar01s03s03.html (for ANT)

The in-place instrumentation is not the reason it doesn't work, since
I manually replace the original classes with the instrumented ones.

In Eclipse there are 4 ways to define the classloader type (s.
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04389.html).
EMMA works for eclipse, when it gets installed on the ext/ directory
of the JRE and the Eclipse classloader type is set to "ext" (however
EMMA's got just one jar, while cobertura.jar depends on 4 other jars).
I tried putting cobertura.jar on the JRE/ext directory and setting the
Eclipse classloader type to "ext" and it didn't work.
My classes could still not find
cobertura.jar\net\sourceforge\cobertura\coveragedata\HasBeenInstrumented.class.

I also tried for instance to create an Eclipse cobertura plugin (a wrapper

of cobertura.jar and its 4 required jars under lib/), add it as a
dependency 
to my plugins and then integrate it to my build process (without any
references 
to it of course). While in the Eclipse IDE my plugins set to depend on my
new 
cobertura plugin could reference class coveragedata\HasBeenInstrumented
the 
generated byte code instrumented into my plugins in the scope of the
testing 
process still did not work.

I read somewhere that EMMA and cobertura generate pretty different
instrumented byte codes, so I just guessed, that the way the generated 
byte code references the cobertura classes was the problem.
For this reason and because it seems I was not the only one who tried
to integrate cobertura to Eclipse PDE (Plugin Development Environment)
I posted this issue under feature requests and not as a bug.

I hope that that could clear up things a little bit.
Kind regards,
neo

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

Comment By: John Lewis (lewijw)
Date: 2008-07-28 14:22

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

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 09:01
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558

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

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-07-30 15:41

Message:
Logged In: NO 

I'm having the same problem, even adding cobertura.jar along with the asm,
jakarta and log4j jars to the ext/ dir and using that bootloader doesn't
seem to help here.

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

Comment By: nchaitas (nchaitas)
Date: 2008-07-30 15:29

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

Hi!
One more piece of information that might be useful.
Cobertura gets executed through use of the <junit> Ant task (according to
its instructions), while Eclipse automated tests get executed through the
<java> Ant task (also with fork="true" and , which accept the Ant elements
<jvmarg>, <sysproperty> and <classpath>, which I used to specify the type
of the class loader, the location of the cobertura.ser and of my
instrumented classes respectively. In particular the invocation of this
<java> task looked like this (in my very first attempt):
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
    		  	<fileset dir="${eclipse-home}/plugins">
            	<include name="org.eclipse.equinox.launcher_*.jar"/>
          	</fileset>
	        </classpath>
		    <arg line="-application ${application}"/>
		    <arg line="-data ${data-dir}"/>
		    <arg line="formatter=${formatter},${test-output}"/>
		    <arg line="-testPluginName ${plugin-name}"/>
		    <arg line="-className ${classname}"/>
		    <arg line="-os ${os}"/>
		    <arg line="-ws ${ws}"/>
		    <arg line="-arch ${arch}"/>
		    <arg line="-consolelog"/>
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		    <sysproperty key="PLUGIN_PATH" value="${plugin-path}"/> 
			 	<!-- Define cobertura specific elements -->
				<sysproperty key="net.sourceforge.cobertura.datafile"
file="${coberturaScripts}/cobertura.ser" />
		    <classpath>
		      <fileset dir="${instrumented}">
		        <include name="**/*.jar"/>
		      </fileset>
		      <fileset dir="${jars}">
		        <include name="**/*.jar"/>
		      </fileset>
	    	</classpath>
				<classpath refid="cobertura.classpath" />
		</java>

As long as I don't instrument my classes and I don't define any cobertura
specific elements in this <java> task my tests run normally.
When I instrument my classes and I use the <junit> task as described in
the cobertura instructions then (after getting an output of many exceptions
on the console upon initialization) only some of my tests get executed, I
assume these are the ones that can get executed as junit tests as well as
junit (Eclipse) plugin tests.

I hope that something of all these could be useful... :o)
Regards,
neo

PS: By the way -even if this does not actually belong to this discussion-,
I had problems with the <cobertura-report> task, particularly with defining
the set of the source files of my multiple eclipse plugin-projects. This
problem is documented very good here
(https://sourceforge.net/mailarchive/forum.php?thread_name=780385.62813.qm%40web56601.mail.re3.yahoo.com&forum_name=cobertura-devel)
by another user and the solution proposed there (namely the use of groovy
ant task) did work for me, indeed! However, I believe that allowing the Ant
element <dirset> to <cobertura-report> task would be the clean solution for
defining multiple source packages. In my opinion a feature request upon
that too is not such a bad idea, since the use of the <cobertura-merge>
task to merge multiple coverage data files is not so convenient.


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

Comment By: nchaitas (nchaitas)
Date: 2008-07-29 11:55

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

Hi John,

thanks for your response.
Unfortunately I am not familiar with the way the code coverage tools
instrument the classes, but it seems that you do, so I appreciate a
lot your assistance!

The EMMA link you mentioned is:
http://emma.sourceforge.net/userguide/ar01s02s03.html (for command line)
and
http://emma.sourceforge.net/userguide/ar01s03s03.html (for ANT)

The in-place instrumentation is not the reason it doesn't work, since
I manually replace the original classes with the instrumented ones.

In Eclipse there are 4 ways to define the classloader type (s.
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04389.html).
EMMA works for eclipse, when it gets installed on the ext/ directory
of the JRE and the Eclipse classloader type is set to "ext" (however
EMMA's got just one jar, while cobertura.jar depends on 4 other jars).
I tried putting cobertura.jar on the JRE/ext directory and setting the
Eclipse classloader type to "ext" and it didn't work.
My classes could still not find
cobertura.jar\net\sourceforge\cobertura\coveragedata\HasBeenInstrumented.class.

I also tried for instance to create an Eclipse cobertura plugin (a wrapper

of cobertura.jar and its 4 required jars under lib/), add it as a
dependency 
to my plugins and then integrate it to my build process (without any
references 
to it of course). While in the Eclipse IDE my plugins set to depend on my
new 
cobertura plugin could reference class coveragedata\HasBeenInstrumented
the 
generated byte code instrumented into my plugins in the scope of the
testing 
process still did not work.

I read somewhere that EMMA and cobertura generate pretty different
instrumented byte codes, so I just guessed, that the way the generated 
byte code references the cobertura classes was the problem.
For this reason and because it seems I was not the only one who tried
to integrate cobertura to Eclipse PDE (Plugin Development Environment)
I posted this issue under feature requests and not as a bug.

I hope that that could clear up things a little bit.
Kind regards,
neo

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

Comment By: John Lewis (lewijw)
Date: 2008-07-28 12:22

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

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 11:01
Message generated for change (Comment added) made by nchaitas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558

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

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

>Comment By: nchaitas (nchaitas)
Date: 2008-07-30 17:29

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

Hi!
One more piece of information that might be useful.
Cobertura gets executed through use of the <junit> Ant task (according to
its instructions), while Eclipse automated tests get executed through the
<java> Ant task (also with fork="true" and , which accept the Ant elements
<jvmarg>, <sysproperty> and <classpath>, which I used to specify the type
of the class loader, the location of the cobertura.ser and of my
instrumented classes respectively. In particular the invocation of this
<java> task looked like this (in my very first attempt):
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
    		  	<fileset dir="${eclipse-home}/plugins">
            	<include name="org.eclipse.equinox.launcher_*.jar"/>
          	</fileset>
	        </classpath>
		    <arg line="-application ${application}"/>
		    <arg line="-data ${data-dir}"/>
		    <arg line="formatter=${formatter},${test-output}"/>
		    <arg line="-testPluginName ${plugin-name}"/>
		    <arg line="-className ${classname}"/>
		    <arg line="-os ${os}"/>
		    <arg line="-ws ${ws}"/>
		    <arg line="-arch ${arch}"/>
		    <arg line="-consolelog"/>
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		    <sysproperty key="PLUGIN_PATH" value="${plugin-path}"/> 
			 	<!-- Define cobertura specific elements -->
				<sysproperty key="net.sourceforge.cobertura.datafile"
file="${coberturaScripts}/cobertura.ser" />
		    <classpath>
		      <fileset dir="${instrumented}">
		        <include name="**/*.jar"/>
		      </fileset>
		      <fileset dir="${jars}">
		        <include name="**/*.jar"/>
		      </fileset>
	    	</classpath>
				<classpath refid="cobertura.classpath" />
		</java>

As long as I don't instrument my classes and I don't define any cobertura
specific elements in this <java> task my tests run normally.
When I instrument my classes and I use the <junit> task as described in
the cobertura instructions then (after getting an output of many exceptions
on the console upon initialization) only some of my tests get executed, I
assume these are the ones that can get executed as junit tests as well as
junit (Eclipse) plugin tests.

I hope that something of all these could be useful... :o)
Regards,
neo

PS: By the way -even if this does not actually belong to this discussion-,
I had problems with the <cobertura-report> task, particularly with defining
the set of the source files of my multiple eclipse plugin-projects. This
problem is documented very good here
(https://sourceforge.net/mailarchive/forum.php?thread_name=780385.62813.qm%40web56601.mail.re3.yahoo.com&forum_name=cobertura-devel)
by another user and the solution proposed there (namely the use of groovy
ant task) did work for me, indeed! However, I believe that allowing the Ant
element <dirset> to <cobertura-report> task would be the clean solution for
defining multiple source packages. In my opinion a feature request upon
that too is not such a bad idea, since the use of the <cobertura-merge>
task to merge multiple coverage data files is not so convenient.


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

Comment By: nchaitas (nchaitas)
Date: 2008-07-29 13:55

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

Hi John,

thanks for your response.
Unfortunately I am not familiar with the way the code coverage tools
instrument the classes, but it seems that you do, so I appreciate a
lot your assistance!

The EMMA link you mentioned is:
http://emma.sourceforge.net/userguide/ar01s02s03.html (for command line)
and
http://emma.sourceforge.net/userguide/ar01s03s03.html (for ANT)

The in-place instrumentation is not the reason it doesn't work, since
I manually replace the original classes with the instrumented ones.

In Eclipse there are 4 ways to define the classloader type (s.
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04389.html).
EMMA works for eclipse, when it gets installed on the ext/ directory
of the JRE and the Eclipse classloader type is set to "ext" (however
EMMA's got just one jar, while cobertura.jar depends on 4 other jars).
I tried putting cobertura.jar on the JRE/ext directory and setting the
Eclipse classloader type to "ext" and it didn't work.
My classes could still not find
cobertura.jar\net\sourceforge\cobertura\coveragedata\HasBeenInstrumented.class.

I also tried for instance to create an Eclipse cobertura plugin (a wrapper

of cobertura.jar and its 4 required jars under lib/), add it as a
dependency 
to my plugins and then integrate it to my build process (without any
references 
to it of course). While in the Eclipse IDE my plugins set to depend on my
new 
cobertura plugin could reference class coveragedata\HasBeenInstrumented
the 
generated byte code instrumented into my plugins in the scope of the
testing 
process still did not work.

I read somewhere that EMMA and cobertura generate pretty different
instrumented byte codes, so I just guessed, that the way the generated 
byte code references the cobertura classes was the problem.
For this reason and because it seems I was not the only one who tried
to integrate cobertura to Eclipse PDE (Plugin Development Environment)
I posted this issue under feature requests and not as a bug.

I hope that that could clear up things a little bit.
Kind regards,
neo

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

Comment By: John Lewis (lewijw)
Date: 2008-07-28 14:22

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

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 11:01
Message generated for change (Comment added) made by nchaitas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558

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

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

>Comment By: nchaitas (nchaitas)
Date: 2008-07-29 13:55

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

Hi John,

thanks for your response.
Unfortunately I am not familiar with the way the code coverage tools
instrument the classes, but it seems that you do, so I appreciate a
lot your assistance!

The EMMA link you mentioned is:
http://emma.sourceforge.net/userguide/ar01s02s03.html (for command line)
and
http://emma.sourceforge.net/userguide/ar01s03s03.html (for ANT)

The in-place instrumentation is not the reason it doesn't work, since
I manually replace the original classes with the instrumented ones.

In Eclipse there are 4 ways to define the classloader type (s.
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04389.html).
EMMA works for eclipse, when it gets installed on the ext/ directory
of the JRE and the Eclipse classloader type is set to "ext" (however
EMMA's got just one jar, while cobertura.jar depends on 4 other jars).
I tried putting cobertura.jar on the JRE/ext directory and setting the
Eclipse classloader type to "ext" and it didn't work.
My classes could still not find
cobertura.jar\net\sourceforge\cobertura\coveragedata\HasBeenInstrumented.class.

I also tried for instance to create an Eclipse cobertura plugin (a wrapper

of cobertura.jar and its 4 required jars under lib/), add it as a
dependency 
to my plugins and then integrate it to my build process (without any
references 
to it of course). While in the Eclipse IDE my plugins set to depend on my
new 
cobertura plugin could reference class coveragedata\HasBeenInstrumented
the 
generated byte code instrumented into my plugins in the scope of the
testing 
process still did not work.

I read somewhere that EMMA and cobertura generate pretty different
instrumented byte codes, so I just guessed, that the way the generated 
byte code references the cobertura classes was the problem.
For this reason and because it seems I was not the only one who tried
to integrate cobertura to Eclipse PDE (Plugin Development Environment)
I posted this issue under feature requests and not as a bug.

I hope that that could clear up things a little bit.
Kind regards,
neo

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

Comment By: John Lewis (lewijw)
Date: 2008-07-28 14:22

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

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 04:01
Message generated for change (Comment added) made by lewijw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558

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

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

>Comment By: John Lewis (lewijw)
Date: 2008-07-28 07:22

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

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

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

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

[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

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

Feature Requests item #2030120, was opened at 2008-07-28 11:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558

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

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

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

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

[ cobertura-Feature Requests-1986558 ] Ignores and Branch Coverage

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

Feature Requests item #1986558, was opened at 2008-06-06 07:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1986558&group_id=130558

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

Initial Comment:
It would be nice to see any specified Ignores also ignored in Branch coverage. Example:

if (logger.isDebugEnabled()) {
    logger.debug("Something");
}

If I specify an ignore for commons-logging, or log4j, the logger.debug line is ignored, but I still get a warning on the branch coverage (50%).


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

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

[ cobertura-Feature Requests-1983926 ] color unsufficient conditional coverage in yellow

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

Feature Requests item #1983926, was opened at 2008-06-03 23:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1983926&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Malte Finsterwalder (finsterwalder)
Assigned to: Nobody/Anonymous (nobody)
Summary: color unsufficient conditional coverage in yellow

Initial Comment:
Lines with unsufficient conditional coverage are now colored in red. On first glance it's easy to get this messed up with uncovered lines, which are also red.
It would be nice to destinguish unsufficient conditional coverage from no coverage and I suggest that yellow is the perfect middle between green and red.

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

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

[ cobertura-Feature Requests-1959691 ] Better Handling of Asserts

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

Feature Requests item #1959691, was opened at 2008-05-07 13:18
Message generated for change (Comment added) made by alangutierrez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1959691&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: John Lewis (lewijw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better Handling of Asserts

Initial Comment:

Ian Dickinson wrote:

Sorry if this has been asked before; I did look in the archives but couldn't find anything.

I'm getting low branch coverage on code that includes java asserts to encode invariants. For example:

public void setFoo( String foo ) {
    assert foo != null;
    this.foo = foo;
}


@Test
public void testSetFoo() {
    new MockFoo.setFoo( "bar" );
}

@Test (expected=java.lang.AssertionError.class)
public void testSetFoo() {
    new MockFoo().setFoo( null );
}

I can execute both tests successfully, but cobertura will tell me that line with the assert was executed twice but did not traverse all branches.  I'm passing -ea to the JVM to enable the assertions, which I can see is working since the tests themselves all pass.

I'm using the cobertura 1.9 plugin for Maven2 on Java6 (I've tried both 6u6 and 6u4).

Any suggestions?

Thanks,
Ian


Jeffrey Bennett replied:

To get full coverage, you'd need to run 3 tests:
1.) Asserts off
2.) Asserts on, conditional true
3.) Asserts on, conditional false

You've done #2 and #3

To my knowledge, there's no good way of doing all 3 tests leading to a source of friction between Cobertura and asserts.



Ian replied:

OK, I understand. Would it be possible to have the branch coverage algorithm take this into account? I don't know if the VM args are captured in the .ser file, but if so it might be possible (I'm guessing here, I admit) for the branch coverage calculator to note that there are two possible worlds (your #1 vs #2 + #3), and depending which one is the "real" world adjust the statistics so that the code either tests one of the one possible branches, or two of the possible two.

And if that isn't impossible, can I make it a feature request please? :-)


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

Comment By: Alan Gutierrez (alangutierrez)
Date: 2008-06-03 08:19

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

Please implement this feature. Ideally, Cobertura would not expect to see
#3 even when asserts were on. An assert is a condition that should never be
true. A very fruitless execerise to test the Java assert mechanism.

Certainly, running Cobertura with asserts off should only test #1 and not
expect #2 or #3.

I would be so happy to see this implemented.

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

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

[ cobertura-Feature Requests-1959691 ] Better Handling of Asserts

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

Feature Requests item #1959691, was opened at 2008-05-07 13:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1959691&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: John Lewis (lewijw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better Handling of Asserts

Initial Comment:

Ian Dickinson wrote:

Sorry if this has been asked before; I did look in the archives but couldn't find anything.

I'm getting low branch coverage on code that includes java asserts to encode invariants. For example:

public void setFoo( String foo ) {
    assert foo != null;
    this.foo = foo;
}


@Test
public void testSetFoo() {
    new MockFoo.setFoo( "bar" );
}

@Test (expected=java.lang.AssertionError.class)
public void testSetFoo() {
    new MockFoo().setFoo( null );
}

I can execute both tests successfully, but cobertura will tell me that line with the assert was executed twice but did not traverse all branches.  I'm passing -ea to the JVM to enable the assertions, which I can see is working since the tests themselves all pass.

I'm using the cobertura 1.9 plugin for Maven2 on Java6 (I've tried both 6u6 and 6u4).

Any suggestions?

Thanks,
Ian


Jeffrey Bennett replied:

To get full coverage, you'd need to run 3 tests:
1.) Asserts off
2.) Asserts on, conditional true
3.) Asserts on, conditional false

You've done #2 and #3

To my knowledge, there's no good way of doing all 3 tests leading to a source of friction between Cobertura and asserts.



Ian replied:

OK, I understand. Would it be possible to have the branch coverage algorithm take this into account? I don't know if the VM args are captured in the .ser file, but if so it might be possible (I'm guessing here, I admit) for the branch coverage calculator to note that there are two possible worlds (your #1 vs #2 + #3), and depending which one is the "real" world adjust the statistics so that the code either tests one of the one possible branches, or two of the possible two.

And if that isn't impossible, can I make it a feature request please? :-)


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

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

[ cobertura-Feature Requests-1949957 ] Improvement in Test Coverage

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

Feature Requests item #1949957, was opened at 2008-04-23 13:48
Message generated for change (Comment added) made by ksagar_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1949957&group_id=130558

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

Initial Comment:
I have been asked to display improvements in test coverage between multiple test runs (with the same source code base). The reports are to be tweaked to display previous line coverage,line coverage in the current run and the percentage improvement for each class/package. 

This can be done easily using old cobertura.ser file and tweaking the report generation process. 

Could you please let me know if i have to get approvals from Sourceforge in order to tweak the Cobertura report generation process (and Cobertura-Maven plug-in) to show code coverage improvements between test runs. 
Immediate response is highly appreciated.

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

Comment By: KIRAN KUMAR KSHIRASAGAR (ksagar_k)
Date: 2008-04-23 14:15

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

Thanks a lot !! I will try uploading the source code changes. Please let
me know if it is useful.

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

Comment By: John Lewis (lewijw)
Date: 2008-04-23 14:06

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

As long as the tweaked code keeps the same license, no approvals are
necessary.   That is the whole point of using open source code.

I encourage you to submit a patch with the changes.   Maybe we will add it
in.   It sounds like an interesting feature.


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

Comment By: KIRAN KUMAR KSHIRASAGAR (ksagar_k)
Date: 2008-04-23 14:02

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

This is submitted by me. Please let me know the response asap. Thanks in
advance !

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

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

[ cobertura-Feature Requests-1949957 ] Improvement in Test Coverage

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

Feature Requests item #1949957, was opened at 2008-04-23 12:48
Message generated for change (Comment added) made by lewijw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1949957&group_id=130558

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

Initial Comment:
I have been asked to display improvements in test coverage between multiple test runs (with the same source code base). The reports are to be tweaked to display previous line coverage,line coverage in the current run and the percentage improvement for each class/package. 

This can be done easily using old cobertura.ser file and tweaking the report generation process. 

Could you please let me know if i have to get approvals from Sourceforge in order to tweak the Cobertura report generation process (and Cobertura-Maven plug-in) to show code coverage improvements between test runs. 
Immediate response is highly appreciated.

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

>Comment By: John Lewis (lewijw)
Date: 2008-04-23 13:06

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

As long as the tweaked code keeps the same license, no approvals are
necessary.   That is the whole point of using open source code.

I encourage you to submit a patch with the changes.   Maybe we will add it
in.   It sounds like an interesting feature.


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

Comment By: KIRAN KUMAR KSHIRASAGAR (ksagar_k)
Date: 2008-04-23 13:02

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

This is submitted by me. Please let me know the response asap. Thanks in
advance !

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

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

[ cobertura-Feature Requests-1949957 ] Improvement in Test Coverage

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

Feature Requests item #1949957, was opened at 2008-04-23 13:48
Message generated for change (Comment added) made by ksagar_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1949957&group_id=130558

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

Initial Comment:
I have been asked to display improvements in test coverage between multiple test runs (with the same source code base). The reports are to be tweaked to display previous line coverage,line coverage in the current run and the percentage improvement for each class/package. 

This can be done easily using old cobertura.ser file and tweaking the report generation process. 

Could you please let me know if i have to get approvals from Sourceforge in order to tweak the Cobertura report generation process (and Cobertura-Maven plug-in) to show code coverage improvements between test runs. 
Immediate response is highly appreciated.

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

Comment By: KIRAN KUMAR KSHIRASAGAR (ksagar_k)
Date: 2008-04-23 14:02

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

This is submitted by me. Please let me know the response asap. Thanks in
advance !

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

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

[ cobertura-Feature Requests-1949957 ] Improvement in Test Coverage

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

Feature Requests item #1949957, was opened at 2008-04-23 10:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1949957&group_id=130558

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

Initial Comment:
I have been asked to display improvements in test coverage between multiple test runs (with the same source code base). The reports are to be tweaked to display previous line coverage,line coverage in the current run and the percentage improvement for each class/package. 

This can be done easily using old cobertura.ser file and tweaking the report generation process. 

Could you please let me know if i have to get approvals from Sourceforge in order to tweak the Cobertura report generation process (and Cobertura-Maven plug-in) to show code coverage improvements between test runs. 
Immediate response is highly appreciated.

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

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

[ cobertura-Feature Requests-1443252 ] Mark untestable code

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

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

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

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

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

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

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

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

Comment By: Luc Maisonobe (maisonobe)
Date: 2008-04-10 20:18

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

I also really miss this feature.
Currently, popular programming rules like adding private constructors to
utility methods or adding a default case in switch statement even if all
cases are already covered reduce code coverage despite they are enforced by
other tools (like chekstyle).
It is currently impossible to have the two tools happy at the same time,
and one must continuously manually check the output to make sure the
non-covered part are not due to bad testing.
This is important for some critical applications where the coverage
objectives are really high.

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

Comment By: Gary Levin (gmlevin)
Date: 2008-02-27 22:57

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

Another vote for this.  Some checked exceptions (like
InterruptedException) are difficult to meaningfully trigger, particularly
in Unit Test.  

The notation can be whatever fits your model.  

Is this scheduled for development?  Still marked as unassigned.

Cobertura works very well.  Thanks for a useful tool.

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

Comment By: Rodrigo Ruiz (nodens2k)
Date: 2008-02-14 10:21

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

Both Javadoc tags and annotations would be perfect for me. I don't see any
reason to choose only one of them.

Private constructors are the most common ones in my code, but I agree with
jalbert631. There are some cases where a unit test is not the right way to
go. Simulating hardware errors and some invalid data conditions fit better
in the integration test phase. Sometimes, it is just impossible to automate
the test, and it must be tested manually.


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

Comment By: Jiri Mares (jirimares)
Date: 2007-12-12 19:36

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

Annotation? I don't think so ... 

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

Comment By: Michael (michael6666)
Date: 2007-12-12 15:39

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

I'd like to vote for this feature. It would make cobertura *much* more
convenient to use, which is stated as one of cobertura's main strengths on
its home page.

Did you already consider using annotations to mark methods as "not to be
tested"?


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

Comment By: Jiri Mares (jirimares)
Date: 2007-09-13 07:36

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

We have been speaking about something like you are describing and the
semi-decision we made was to reuse the clover comments, maybe to introduce
some cobertura's one. So we know about this problem and want to solve it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Message:
Logged In: YES 
user_id=437864

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

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

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

[ cobertura-Feature Requests-1925513 ] add JMX interface to write coverage data

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

Feature Requests item #1925513, was opened at 2008-03-25 13:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1925513&group_id=130558

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

Initial Comment:
JMX is a simple way to allow writting coverage data file without stopping the application server

Then with a JMX client, it is easy for end-user to trigger a dump of coverage data, and it would be also possible to control other features of Cobertura dynamically (without application server shutdown).

Exporting this MBean to the MBeanServer can be done at startup by a dedicated servlet (i.e. register the mbean in the initialize method of the servlet, and unregister the MBean in the destroy method).

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

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

[ cobertura-Feature Requests-1443252 ] Mark untestable code

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

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

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

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

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

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

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

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

Comment By: Gary Levin (gmlevin)
Date: 2008-02-27 16:57

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

Another vote for this.  Some checked exceptions (like
InterruptedException) are difficult to meaningfully trigger, particularly
in Unit Test.  

The notation can be whatever fits your model.  

Is this scheduled for development?  Still marked as unassigned.

Cobertura works very well.  Thanks for a useful tool.

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

Comment By: Rodrigo Ruiz (nodens2k)
Date: 2008-02-14 04:21

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

Both Javadoc tags and annotations would be perfect for me. I don't see any
reason to choose only one of them.

Private constructors are the most common ones in my code, but I agree with
jalbert631. There are some cases where a unit test is not the right way to
go. Simulating hardware errors and some invalid data conditions fit better
in the integration test phase. Sometimes, it is just impossible to automate
the test, and it must be tested manually.


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

Comment By: Jiri Mares (jirimares)
Date: 2007-12-12 13:36

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

Annotation? I don't think so ... 

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

Comment By: Michael (michael6666)
Date: 2007-12-12 09:39

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

I'd like to vote for this feature. It would make cobertura *much* more
convenient to use, which is stated as one of cobertura's main strengths on
its home page.

Did you already consider using annotations to mark methods as "not to be
tested"?


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

Comment By: Jiri Mares (jirimares)
Date: 2007-09-13 00:36

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

We have been speaking about something like you are describing and the
semi-decision we made was to reuse the clover comments, maybe to introduce
some cobertura's one. So we know about this problem and want to solve it.

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

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

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

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

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

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

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

Comment By: Kasper B. Graversen (kbg)
Date: 2007-09-11 23:48

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

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

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

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

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

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

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

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

Message:
Logged In: YES 
user_id=437864

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

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

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

[ cobertura-Feature Requests-1443252 ] Mark untestable code

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

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

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

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

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

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

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

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

Comment By: Rodrigo Ruiz (nodens2k)
Date: 2008-02-14 10:21

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

Both Javadoc tags and annotations would be perfect for me. I don't see any
reason to choose only one of them.

Private constructors are the most common ones in my code, but I agree with
jalbert631. There are some cases where a unit test is not the right way to
go. Simulating hardware errors and some invalid data conditions fit better
in the integration test phase. Sometimes, it is just impossible to automate
the test, and it must be tested manually.


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

Comment By: Jiri Mares (jirimares)
Date: 2007-12-12 19:36

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

Annotation? I don't think so ... 

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

Comment By: Michael (michael6666)
Date: 2007-12-12 15:39

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

I'd like to vote for this feature. It would make cobertura *much* more
convenient to use, which is stated as one of cobertura's main strengths on
its home page.

Did you already consider using annotations to mark methods as "not to be
tested"?


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

Comment By: Jiri Mares (jirimares)
Date: 2007-09-13 07:36

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

We have been speaking about something like you are describing and the
semi-decision we made was to reuse the clover comments, maybe to introduce
some cobertura's one. So we know about this problem and want to solve it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Message:
Logged In: YES 
user_id=437864

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

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

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

[ cobertura-Feature Requests-1885285 ] store uncalculated rates in report xml

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

Feature Requests item #1885285, was opened at 2008-02-02 11:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1885285&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Sellers (jimsellers)
Assigned to: Nobody/Anonymous (nobody)
Summary: store uncalculated rates in report xml

Initial Comment:
To be able to easily use the generated coverage xml file it would be great to have the "raw" values and not just the calculated rates.

This should only be a small change to the xml and it would allow other systems to leverage cobertura much better.

Example how it's now:
<coverage line-rate="0.34824640287769787" branch-rate="0.2467021522795649" version="1.9" timestamp="1181783168140">
...

How I think that it would be useful:
<coverage line-rate="0.34824640287769787" loc="123" coveredloc="23" branch-rate="0.2467021522795649" branches="42" coveredBranchs="13" version="2.0" timestamp="1181783168140">


Similar requests have been made on the mailing list: http://www.nabble.com/XML-report-format-changes-proposal-td14412972.html

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

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

[ cobertura-Feature Requests-1443252 ] Mark untestable code

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

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

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

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

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

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

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

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

>Comment By: Jiri Mares (jirimares)
Date: 2007-12-12 19:36

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

Annotation? I don't think so ... 

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

Comment By: Michael (michael6666)
Date: 2007-12-12 15:39

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

I'd like to vote for this feature. It would make cobertura *much* more
convenient to use, which is stated as one of cobertura's main strengths on
its home page.

Did you already consider using annotations to mark methods as "not to be
tested"?


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

Comment By: Jiri Mares (jirimares)
Date: 2007-09-13 07:36

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

We have been speaking about something like you are describing and the
semi-decision we made was to reuse the clover comments, maybe to introduce
some cobertura's one. So we know about this problem and want to solve it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Message:
Logged In: YES 
user_id=437864

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

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

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

[ cobertura-Feature Requests-1443252 ] Mark untestable code

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

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

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

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

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

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

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

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

Comment By: Michael (michael6666)
Date: 2007-12-12 15:39

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

I'd like to vote for this feature. It would make cobertura *much* more
convenient to use, which is stated as one of cobertura's main strengths on
its home page.

Did you already consider using annotations to mark methods as "not to be
tested"?


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

Comment By: Jiri Mares (jirimares)
Date: 2007-09-13 07:36

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

We have been speaking about something like you are describing and the
semi-decision we made was to reuse the clover comments, maybe to introduce
some cobertura's one. So we know about this problem and want to solve it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Message:
Logged In: YES 
user_id=437864

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

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

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

[ cobertura-Feature Requests-1815191 ] Cobertura should support JAR, WAR, RAR and EAR files

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

Feature Requests item #1815191, was opened at 2007-10-17 10:53
Message generated for change (Comment added) made by lewijw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1815191&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Jeff MAURY (jeffmaury)
Assigned to: John Lewis (lewijw)
Summary: Cobertura should support JAR, WAR, RAR and EAR files

Initial Comment:
It would be nice if Cobertura should be able to work on JAR, WAR, ... files instead of only directories of classes.
It would allow a better use and integration (Maven and Cargo for example)

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

>Comment By: John Lewis (lewijw)
Date: 2007-10-18 09:33

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

Hi Jeff,

It will process the jars as well.

Thanks for your interest in Cobertura!

John

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

Comment By: Jeff MAURY (jeffmaury)
Date: 2007-10-18 09:21

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

What is the result of such task: will it instrument classes under
WEB-INF/classes only or will it process also JARs under WEB-INF/lib ?

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

Comment By: John Lewis (lewijw)
Date: 2007-10-17 11:56

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

This is already possible.  Do something like this:

		<cobertura-instrument datafile="${basedir}/cobertura.ser"
todir="${instrumented.dir}">
			<includeClasses regex="test.*" />
			<excludeClasses regex="test.*.B" />
			<excludeClasses regex=".*Test*" />
			<fileset dir="${tmp.dir}">
				<include name="app.war" />
			</fileset>
		</cobertura-instrument>


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

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

[ cobertura-Feature Requests-1815191 ] Cobertura should support JAR, WAR, RAR and EAR files

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

Feature Requests item #1815191, was opened at 2007-10-17 17:53
Message generated for change (Comment added) made by jeffmaury
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1815191&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Jeff MAURY (jeffmaury)
Assigned to: John Lewis (lewijw)
Summary: Cobertura should support JAR, WAR, RAR and EAR files

Initial Comment:
It would be nice if Cobertura should be able to work on JAR, WAR, ... files instead of only directories of classes.
It would allow a better use and integration (Maven and Cargo for example)

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

>Comment By: Jeff MAURY (jeffmaury)
Date: 2007-10-18 16:21

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

What is the result of such task: will it instrument classes under
WEB-INF/classes only or will it process also JARs under WEB-INF/lib ?

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

Comment By: John Lewis (lewijw)
Date: 2007-10-17 18:56

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

This is already possible.  Do something like this:

		<cobertura-instrument datafile="${basedir}/cobertura.ser"
todir="${instrumented.dir}">
			<includeClasses regex="test.*" />
			<excludeClasses regex="test.*.B" />
			<excludeClasses regex=".*Test*" />
			<fileset dir="${tmp.dir}">
				<include name="app.war" />
			</fileset>
		</cobertura-instrument>


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

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