__matthewHawthorne wrote:
I agree with the idea about testing all Java versions. Testing all platforms is important too. In theory, it seems like we need some type of text matrix, in which we identify all platforms and JREs that the software has been tested on.
Something like:
1.2 1.3 1.4 Solaris x Linux x x x Windows x BSD x x Mac OSX x x
Even if we are not able to access every version on every platform, it would be nice to see this information. Users who have access to an untested platform could volunteer to run the tests and submit the results.
Is this overkill?
Gary Gregory wrote:
I agree with all of your responses, I was being a bit paranoid ;-)
What about Java versions: 1.2 vs 1.3 vs 1.4? Hopefully a released component
has been tested on all. Perhaps this should be part of the release
procedure: "Make sure the build runs on JDK a, b, and c". I am not sure we
have such a guarantee, at least it is not advertised in the release notes or
on the web presence for a component: "These unit tests pass on JRE a, b, and
c"-type of statement. Sometimes we catch a 1.4 API call in [lang] and we
clean that up, good. But what about 1.3 vs 1.2? Far fetched perhaps but it
would be good to know for sure.
Thanks for your patience, :-) Gary
-----Original Message----- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 09:46 To: Jakarta Commons Developers List Subject: Re: [lang][codec] Sanity checking a client project build
You're definitely not nuts, but perhaps a little paranoid ;).
From what I've seen, it seems to be a prereq of any released commons component that ALL unit tests must pass. This is one of the reasons that I've never had a doubt about creating a dependency on any project from commons.
So, while invoking these tests from your own project does seem safe, it also seems unnecessary. The [lang] developers (which of course includes you) are already ensuring that all of the tests pass and that the code is solid.
Now if you're depending on the CVS HEAD, that's a different story. But even in that case, running the tests whenever you do a cvs update seems to be enough.
Although, releasing a unit test jar is an interesting idea.
Summary: A released version of any project passes all tests. Why create the extra work for yourself?
Gary Gregory wrote:
Hello,
I'll start this topic on [lang] and [codec] only since I am active here.
I am considering adding to the unit test suite of /my/ project the unit
tests of 3rd party libraries. Why do this? As a simple sanity check. Our
project uses [lang], [codec], [pool], [cli], [collections], Xerces,
Xalan. I
would like the confidence added to /my/ project, that all of these
pieces
are working as advertised and that no side effects exists.
This is why I would like to suggest that [lang] and [codec] deliver
their
unit tests in jar files instead of plain source.
A secondary point I have not thought through is how do you know which
tests
to invoke. The build.xml file contains a test target which I could
invoke
from my build file but I like to use the Ant/Junit reporting feature. I
do
not want to impose this requirement on the build.xml file for a project
of
course.
Any thought? Am I nuts? Paranoid?
Thanks, Gary
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
