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 Wed, 15 Mar 2006 09:35:43 GMT
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 <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
> >
> >
>
>


--
Thanks,
Stepan Mishura
Intel Middleware Products Division

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