commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <ma...@phreaker.net>
Subject Re: [lang][codec] Sanity checking a client project build
Date Fri, 21 Nov 2003 18:50:22 GMT
Whoops, I meant "test matrix".


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


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


Mime
View raw message