[lang][codec] Sanity checking a client project build

[Gary Gregory <gg...@seagullsw.com>]

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

Re: [lang][codec] Sanity checking a client project build

[John Keyes <jb...@mac.com>]

> 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.

Do you require the tests for your OS to make sure it works as 
advertised?
I think you're being a bit paranoid as you should only depend on 
*released*
code not on any dev or snapshot builds.

-John K
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang][codec] Sanity checking a client project build

[__matthewHawthorne <ma...@phreaker.net>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org