harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: [classlib] Testing
Date Thu, 27 Apr 2006 11:15:55 GMT
George Harley wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> George Harley wrote:
>>> Geir Magnusson Jr wrote:
>>>>
>>>> Geir Magnusson Jr wrote:
>>>>>
>>>>> George Harley wrote:
>>>> >>
>>>>>> Of course, the text module has only "implementation-independent 
>>>>>> tests that designed to be run from classpath". For modules that 
>>>>>> have got implementation-specific tests then I suppose we could 
>>>>>> use something like 
>>>>>> "org.apache.harmony.[module].tests.impl.[package under test]" or

>>>>>> "org.apache.harmony.[module].tests.internal.[package under test]"

>>>>>> etc. I've got no preference.
>>>>>
>>>>> -1
>>>>>
>>>>> Put them in the same package as the class being tested, please, if 
>>>>> there is no problem being run that way.
>>>>
>>>> Sorry to be so snippy.  Been a long day.
>>>
>>> Sure. No worries.
>>>
>>>>
>>>> Why would we want this convoluted package name?  Why wouldn't we 
>>>> want to let them be in the same package as the class being tested 
>>>> since it's implementation testing?
>>>
>>> OK, point taken about the long package names that may result for 
>>> tests of org.apache.harmony.* stuff. If the class under test is an 
>>> internal type (i.e. in the org.apache.harmony.* package space) then 
>>> I am sure we can all agree on a sensible abbreviation so that the 
>>> org.apache.harmony part does not appear twice. So, for instance, if 
>>> we are testing public methods on 
>>> org.apache.harmony.security.foo.bar.MyType from the classpath then 
>>> we could have the test package be 
>>> org.apache.harmony.security.tests.foo.bar.
>>>
>>> I am concerned that we are all agree on what we mean by 
>>> "implementation"-specific testing and "internal"-specific testing. I 
>>> know it has been confusing me a lot.
>>
>> Yah - we should probably bottom out there...
>>
>>>
>>> If we want to run API tests that are specific to our implementation 
>>> then there is no need to have the test types in the same package 
>>> name as the class under test and no need for those tests to be on 
>>> the bootclasspath. Orthogonal to that are tests that are actually 
>>> testing the internals of a type - these are what I take to be 
>>> candidates for being in the same package and on the bootclasspath at 
>>> test time.
>>
>> So your suggestion is?  I agree with you, but when reading the above, 
>> I was expecting some kind of "therefore, I think we should...".  it 
>> could just be that I have no coffee this a.m.
>>
>> geir
>
> Hi,
>
> Actually it was me who was suffering the effects of caffeine 
> deficiency. All rectified now :-)
>
> Right, here is a sort of "therefore" that you correctly noticed was 
> missing from my previous note. It's probably more a cry for help as I 
> try and grasp towards simplicity.
>
> I really think that there are only two kinds of unit test in the 
> context of this discussion and I think that where in they live in the 
> file system is key.
>
> First, those that are testing public/API methods (both Java API and 
> our implementation-specific org.apache.harmony.* API) and do not need 
> to be run on the bootclasspath. For tests of Java API types, our test 
> classes are in packages called o.a.h.<module>.tests.<package under 
> test>. Those tests that are dealing with API methods of 
> implementation-specific types (o.a.h.*) can be in test packages that 
> are something like o.a.h.<module>.tests.<appropriate package fragment 
> minus any o.a.h duplication. On the file system all of these API tests 
> can live under <module>/src/test/java and be built to a bin location 
> such as bin/main that can be added as a classpath element in our test 
> scripts.

Sorry, I meant that all tests intended to run on the classpath should be 
compiled to bin/test.

>
> Next, we have "internal" tests that are intended to access non-public 
> properties of a type irrespective of whether it is a public API type 
> or an implementation-specific type. These tests are in the same 
> package as the type under test and are intended to run on the 
> bootclasspath. They can live under a separate source folder (e.g. 
> <module>/src/test/java-internal or any other of Paulex's suggestions) 
> and get built to a separate output location (e.g. bin/main-internal) 
> that gets added to the bootclasspath. I like using the "-internal" 
> suffix since it makes it clear that the code under those locations has 
> been written explicitly to reach into the internals of a type.

...likewise, I meant that tests intended for the bootclasspath should be 
compiled to something like a bin/test-internal


>
> Of course the merits of having tests in the same package as the thing 
> under test is another story for another thread but it seems pretty 
> obvious that a lot of folks go for it so I'll respect that.
>
> OK, my coffee cup is empty now.
>
> Best regards,
> George
>
>>
>>>
>>> Best regards,
>>> George
>>>
>>>>
>>>> geir
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message