You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Blake Martin <bl...@gmail.com> on 2008/11/03 17:57:49 UTC
No Cobertura, please
Is there a way to disable Cobertura? When it runs, my test lifecycle is run
again, and I don't want this to happen. I want the POM to behave like
Cobertura doesn't exist.
Is this possible?
RE: No Cobertura, please
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Doesn't cobertura have a skip parameter?
-----Original Message-----
From: Blake Martin [mailto:blakecmartin@gmail.com]
Sent: Monday, November 03, 2008 10:58 AM
To: Maven Users List
Subject: No Cobertura, please
Is there a way to disable Cobertura? When it runs, my test lifecycle is
run
again, and I don't want this to happen. I want the POM to behave like
Cobertura doesn't exist.
Is this possible?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: No Cobertura, please
Posted by Trevor Harmon <tr...@vocaro.com>.
On Nov 3, 2008, at 12:42 PM, Oleg Gusakov wrote:
> Strange, but true analogy - quantum cryptography is so interesting
> because of the same principle: "we cannot observe a phenomena
> without changing it"
Otherwise known as the Heisenbug:
http://en.wikipedia.org/wiki/Unusual_software_bug
Trevor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: No Cobertura, please
Posted by Oleg Gusakov <ol...@gmail.com>.
I concur 100%!
Strange, but true analogy - quantum cryptography is so interesting
because of the same principle: "we cannot observe a phenomena without
changing it"
Stephen Connolly wrote:
> Unless you are trying to do: "Stupid code coverage mistake #1"...
>
> "Stupid code coverage mistake #1" is only running your tests once (usually
> with instrumentation... but the same mistake works the other way around).
> This is a mistake because 99.9% of developers (who try to do this) do not
> understand the JVM specification and the Java Memory Model.
>
> The modifications to bytecode that are performed by code coverage
> instrumentation are perfectly valid under the JVM specification... but they
> can introduce unintended synchronizations between different threads, and
> they can also force the JVM to not optimize / reorder certain operations in
> between synchronization points. A different JVM is entirely at liberty to
> make the same changes (as adding synchronization is permitted for a JVM
> implementation... removing synchronization is not ;-) )
>
> I have seen the following:
>
> 1. Tests pass without coverage, fail with coverage
> 2. Tests fail without coverage, pass with coverage
>
> In both cases the root cause analysis showed that the failure was due to
> badly written code.
>
> (Note there are also cases where #1 was due to the test being a performance
> test... but since these tests all were called xyzPerfTest we knew that was
> the cause)
>
> Trust me when I say: "If you are making a release, or just about to make a
> release, shut up and run the damn tests twice"
>
> If however, you are only trying to speed up running the tests while
> developing... put cobertura in a profile.
>
> 2008/11/3 Stephen Connolly <st...@gmail.com>
>
>
>> put the cobertura plugin configuration in a profile that is not active by
>> default.
>>
>> 2008/11/3 Blake Martin <bl...@gmail.com>
>>
>> Is there a way to disable Cobertura? When it runs, my test lifecycle is run
>>
>>> again, and I don't want this to happen. I want the POM to behave like
>>> Cobertura doesn't exist.
>>>
>>> Is this possible?
>>>
>>>
>>
>
>
Re: No Cobertura, please
Posted by Stephen Connolly <st...@gmail.com>.
Unless you are trying to do: "Stupid code coverage mistake #1"...
"Stupid code coverage mistake #1" is only running your tests once (usually
with instrumentation... but the same mistake works the other way around).
This is a mistake because 99.9% of developers (who try to do this) do not
understand the JVM specification and the Java Memory Model.
The modifications to bytecode that are performed by code coverage
instrumentation are perfectly valid under the JVM specification... but they
can introduce unintended synchronizations between different threads, and
they can also force the JVM to not optimize / reorder certain operations in
between synchronization points. A different JVM is entirely at liberty to
make the same changes (as adding synchronization is permitted for a JVM
implementation... removing synchronization is not ;-) )
I have seen the following:
1. Tests pass without coverage, fail with coverage
2. Tests fail without coverage, pass with coverage
In both cases the root cause analysis showed that the failure was due to
badly written code.
(Note there are also cases where #1 was due to the test being a performance
test... but since these tests all were called xyzPerfTest we knew that was
the cause)
Trust me when I say: "If you are making a release, or just about to make a
release, shut up and run the damn tests twice"
If however, you are only trying to speed up running the tests while
developing... put cobertura in a profile.
2008/11/3 Stephen Connolly <st...@gmail.com>
> put the cobertura plugin configuration in a profile that is not active by
> default.
>
> 2008/11/3 Blake Martin <bl...@gmail.com>
>
> Is there a way to disable Cobertura? When it runs, my test lifecycle is run
>> again, and I don't want this to happen. I want the POM to behave like
>> Cobertura doesn't exist.
>>
>> Is this possible?
>>
>
>
Re: No Cobertura, please
Posted by Stephen Connolly <st...@gmail.com>.
put the cobertura plugin configuration in a profile that is not active by
default.
2008/11/3 Blake Martin <bl...@gmail.com>
> Is there a way to disable Cobertura? When it runs, my test lifecycle is run
> again, and I don't want this to happen. I want the POM to behave like
> Cobertura doesn't exist.
>
> Is this possible?
>