You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Richard Liang <ri...@gmail.com> on 2006/03/11 07:17:00 UTC
Location of test data files (was:How to deal with this kind of serialization
compatibility issue?)
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.
> 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 <ge...@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
Re: Location of test data files
Posted by Tim Ellison <t....@gmail.com>.
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 <ge...@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.
Re: Location of test data files
Posted by George Harley <ge...@googlemail.com>.
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 <ge...@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
>
>
Re: Location of test data files
Posted by Stepan Mishura <st...@gmail.com>.
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 <ge...@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
Re: Location of test data files
Posted by Stepan Mishura <st...@gmail.com>.
Hi George,
>
>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.
>
Agree.
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 <ge...@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
Re: Location of test data files
Posted by Richard Liang <ri...@gmail.com>.
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
>
>
Hello George,
It's good. :-)
>> 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 <ge...@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
>>
>>
>
>
--
Richard Liang
China Software Development Lab, IBM
Re: Location of test data files
Posted by George Harley <ge...@googlemail.com>.
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 <ge...@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
>
>
Re: Location of test data files
Posted by Stepan Mishura <st...@gmail.com>.
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
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 <ge...@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
Re: Location of test data files
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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.
>
Great - that wasn't clear. This works for me.
geir
Re: Location of test data files
Posted by Richard Liang <ri...@gmail.com>.
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 <ge...@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
Re: Location of test data files
Posted by George Harley <ge...@googlemail.com>.
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
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 <ge...@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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
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
Re: Location of test data files
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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