harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Location of test data files
Date Wed, 15 Mar 2006 12:59:16 GMT
Why not describe it in a doc, and submit it for the website?

Regards,
Tim

George Harley wrote:
> 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
>>
>>   
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message