harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: Location of test data files
Date Mon, 13 Mar 2006 14:02:40 GMT
George Harley wrote:
> Richard Liang wrote:
>> 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.
>>>
>> Hello George,
>>
>> It's good to put all test data files for one module into one folder, 
>> such as "src/test/resources". However, there may be other options, 
>> personally I'd like to put the test data file into the same directory 
>> of the test case which uses the data file. This may make the 
>> maintenance work easy. :-)
>> Anyway, I think we shall follow the same style.
>
> Hi Richard,
>
> Just to avoid any ambiguity here, what I proposed was to place the 
> reference serialization files *under* a given module's 
> src/test/resources folder in sub-folders that matched the package name 
> of the test class - and not just have them all in one folder.
>
Yes, George. That's make sense :-)
> For instance, the LUNI module could have a SimpleTimeZoneTest.dat file 
> located in the folder 
> <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
>
> Another alternative would be to use a tree structure that mirrored the 
> package name of the Serializable type under test.
> e.g.
> <MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat

>
>
>
> I think that separating out all test artefacts from actual source code 
> is cleaner and IMHO makes the maintenance easier :-)
>
I think there is no big difference. But anyway we shall agree with one 
of the three options.
1) Put test data files into a separated folder, and use the package name 
of test case as its namespace.
    e.g., <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
2) Put test data files into a separated folder, and use the  package 
name of the class under test as its namespace.
    e.g.
    
<MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat 

3. Put test data files into the same location as the test case.

Shall we vote? :-)
> Using either Ant or <IDE of choice> it is pretty straightforward to 
> get these resources placed on the classpath when the tests are run.
>
Yes. I think we all agree with this.
>
> Best regards,
> George
>
>>
>>> 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
>>>>>
>>>>>   
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


-- 
Richard Liang
China Software Development Lab, IBM



Mime
View raw message