You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/03/12 02:28:55 UTC

Re: Location of test data files


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. :-)

Yes - for maintenance and name collision, this makes sense.  That is how 
security does it now.

geir

Re: Location of test data files

Posted by Geir Magnusson Jr <ge...@pobox.com>.

George Harley wrote:
> Geir Magnusson Jr 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. :-)
>>
>> Yes - for maintenance and name collision, this makes sense.  That is 
>> how security does it now.
>>
>> geir
>>
> Sorry, I don't understand the "name collision" issue. Could you explain ?

I guess it depends on what you are proposing, but if there isn't a 
parallel package structure in resources/ as we have in java/ then we may 
have file name collisions...

geir

> 
> Best regards,
> George
> 
> 

Re: Location of test data files

Posted by George Harley <ge...@googlemail.com>.
Geir Magnusson Jr 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. :-)
>
> Yes - for maintenance and name collision, this makes sense.  That is 
> how security does it now.
>
> geir
>
Sorry, I don't understand the "name collision" issue. Could you explain ?

Best regards,
George