Chris Hostetter wrote:
: Nice. I think we can't include EMMA jars int he repository, though, so
: you'll want to add the ability to download the Jar on the fly, just like
: Grant did it for the benchmark stuff.
that's not strictly neccessary is it? ... coverage reports could just be
an optional part of the build that only works if you've got EMMA installed
-- much the way javacc is.
I haven't really looked at EMMA or this patch, but if it involves an ant
plugin then users pretty much have to install it themselves before
executing ant right?
All users have to do is to download the EMMA jar files and add them to
their ant classpath. It's exactly the same as what they have to do to
get JUnit to work. If the jars cannot be found in the ant classpath the
users get an error message when they execute an EMMA target, saying to
download EMMA. All the other targets (like compile or test) work without
having the EMMA jars as they did before.
It should also be noted, there are *many* code coverage tools ... some may
have more compatible liscences if we do want to make them a *core* part of
the build, but i think leaving it as an optional (but easy to use) part
of the build.xml would be good enough ... in my experience, while code
coverage test reports can be helpfull for spoting big gaps in your unit
tests, they can lead to a false sense of security if you put too much
stock in them...
http://thediscoblog.com/?p=15
I agree. Good coverage does not mean that the quality of the tests is
high. My intention for this patch was just to find gaps in the current
testcases and to help in the future to quickly check if new patches do
not reduce the coverage. It certainly does not replace a thorough
review of patches and testcases.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
