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 <[EMAIL PROTECTED]>:
> >>>>>> ...
> >>>>>>
> >>>>>>
> >>>>>>> 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
