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