harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Location of test data files
Date Mon, 13 Mar 2006 23:47:47 GMT


Stepan Mishura wrote:
> Hi George,
> 
> I like you idea with loading test's resource files. I don't see any
> maintenance issues with putting all resource files into "src/test/resources"
> folder, for example, if a test have several resource files then I'd like to
> keep them in separate folder rather then in a test's folder. Also don't
> think that there will be name collision problems: java files go to
> "test/java" and resource files go to "test/resources". Is anybody going to
> put class files there?

As long as you keep a parallel package tree, it should be equivalent of 
how we do it now.  Not quite sure what we gain other than it's neater...

geir

> 
> George Harley wrote:
>> 2) The need for the "TEST_SRC_DIR" system property goes away if method
>> getDataFile() were updated to use java.net.URI.
>> e.g,
>>
>> protected File getDataFile(int index) {
>>    String name = "/" + this.getClass().getName().replace('.', '/') + "."
>>        + index + ".dat";
>>    return new
>> File(URI.create(this.getClass().getResource(name).toString()));
>>
> 
> FYI, SerializationTest.java is not the only one case. There are few places
> where "TEST_SRC_DIR" system property is used, for example, policy resource
> files see:
> modules/security/test/common/unit/javax/security/auth/PolicyTest.java
> modules/security/test/common/unit/javax/security/auth/jaas_policy1.txt
> modules/security/test/common/unit/javax/security/auth/jaas_policy2.txt
> 
> I think it won't be an issue to fix them if your suggestion will be
> accepted.
> 
> BTW, as far as I remember we agreed to call new security module 'auth'
> because of 'JAAS' trademark issues so I guess we should rename two policy
> files say to auth_policy<n>.txt. I'm going to search all such cases and
> provide a patch.
> 
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
> 
> 
> On 3/11/06, George Harley wrote:
>> Hi Mikhail (again),
>>
>> Just a couple of brief observations about the SerializationTest.java
>> code as it stands in SVN today :
>>
>> 1) The reference/golden .dat files for Serializable classes in a given
>> module could be added under the module's src/test/resources directory
>> (in sub-folders corresponding to their package names). In an Ant build
>> these would be copied under the test bin using a tweaked version of the
>> "copy-test-resources" target (see the proposed changes to
>> make/build-java.xml contained in the HARMONY-57). At runtime this would
>> make the .dat files available from the classpath.
>>
>> 2) The need for the "TEST_SRC_DIR" system property goes away if method
>> getDataFile() were updated to use java.net.URI.
>> e.g,
>>
>> protected File getDataFile(int index) {
>>    String name = "/" + this.getClass().getName().replace('.', '/') + "."
>>        + index + ".dat";
>>    return new
>> File(URI.create(this.getClass().getResource(name).toString()));
>>
>>
>> It seems to me that the src/test/resources directory would be an ideal
>> place to keep a module's reference .dat files.
>>
>> Best regards,
>> George
>>
>>
>> George Harley wrote:
>>> Mikhail Loenko wrote:
>>>> 2006/3/9, George Harley <george.c.harley@googlemail.com>:
>>>> ...
>>>>
>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>
>>>> BTW, there is a framework for serialization testing which is currently
>>>> in the security module:
>>>>
>>>>
>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>>
>>>> It serves to simplify serialization testing and has the docs inside.
>>>> Actually
>>>> almost all serializable security-related classes are tested with this
>>>> framework.
>>>>
>>>> Does it make sense to move the framework to a common place?
>>>>
>>> Hi Mikhail !
>>>
>>> I've spent a little bit of time running this (with a couple of my own
>>> little concrete subclasses of SerializationTest) and I really like it.
>>> It was pretty straightforward to create a JUnit error for the case of
>>> java.util.TimeZone after my overridden version of getData() used
>>> TimeZone.getDefault() to generate a couple of TimeZone instances from
>>> the RI.
>>>
>>> I can definitely see a case for broadening this approach outside just
>>> the security classes. Really impressive stuff !
>>>
>>> Best regards,
>>> George
>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
> 

Mime
View raw message