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: Location of test data files
Date Wed, 15 Mar 2006 12:20:30 GMT
Hi Stepan,

Good idea. I will raise it today. It will only cover the proposed layout 
of these test resources in a given module and not discuss how the 
serialization tests are carried out since that discussion is still ongoing.

Best regards,
George


Stepan Mishura wrote:
> Hi George,
>
> I'd like to fix outcome of this discussion. I think a JIRA issue should
> filed to track tests reorg. As far as it'll be next massive reorg. and can
> not be applied right now (there are other massive updates pending in JIRA).
> And JIRA won't let us to forget about our decision.
>
> Thanks,
> Stepan
>
>
> On 3/14/06, George Harley wrote:
>   
>> Stepan Mishura wrote:
>>     
>>> On 3/13/06, 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.
>>>>
>>>> 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
>>     
>>> To make it more clear because we talked only about data files for
>>>       
>> testing
>>     
>>> serialization but I'm aware of all resource files. So we have the
>>>       
>> following
>>     
>>> proposal:
>>> <MODULE_ROOT>/src/test/resources
>>>     img/               <== image files
>>>     net/               <== net resource files
>>>     other/             <== disembodied files, for example, policy files
>>>     serialization/     <== data files for serialization
>>>
>>> And during the build all resource files will be copied to:
>>>       
>> build/resources
>>     
>>> directory. Right?
>>>
>>> Thanks,
>>> Stepan
>>>
>>>
>>>       
>> Hi Stepan,
>>
>> Yes, that sounds great - with the very minor suggestion that at build
>> time these test resource files go to their corresponding sub-directories
>> under the test bin (e.g. bin/test) which is separate from the bin folder
>> (e.g. bin/main) that the stuff getting tested is compiled to.
>>
>> Best regards,
>> George
>>
>>
>>     
>>> I think that separating out all test artefacts from actual source code
>>>
>>>       
>>>> is cleaner and IMHO makes the maintenance easier :-)
>>>>
>>>> Using either Ant or <IDE of choice> it is pretty straightforward to
get
>>>> these resources placed on the classpath when the tests are run.
>>>>
>>>>
>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>
>>>>>>>               
>>> --
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>       
>>     
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>   


Mime
View raw message