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 <[EMAIL PROTECTED]>
put the cobertura plugin configuration in a profile that is not active by
default.
2008/11/3 Blake Martin <[EMAIL PROTECTED]>
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?
