harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: Location of test data files
Date Tue, 14 Mar 2006 05:37:47 GMT
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 <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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message