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 10:49:48 GMT
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.

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.

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