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 Mon, 13 Mar 2006 10:57:45 GMT
Hi George,

I like you idea with loading test's resource files. I don't see any
maintenance issues with putting all resource files into "src/test/resources"
folder, for example, if a test have several resource files then I'd like to
keep them in separate folder rather then in a test's folder. Also don't
think that there will be name collision problems: java files go to
"test/java" and resource files go to "test/resources". Is anybody going to
put class files there?

George Harley wrote:
> 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()));
>

FYI, SerializationTest.java is not the only one case. There are few places
where "TEST_SRC_DIR" system property is used, for example, policy resource
files see:
modules/security/test/common/unit/javax/security/auth/PolicyTest.java
modules/security/test/common/unit/javax/security/auth/jaas_policy1.txt
modules/security/test/common/unit/javax/security/auth/jaas_policy2.txt

I think it won't be an issue to fix them if your suggestion will be
accepted.

BTW, as far as I remember we agreed to call new security module 'auth'
because of 'JAAS' trademark issues so I guess we should rename two policy
files say to auth_policy<n>.txt. I'm going to search all such cases and
provide a patch.

Thanks,
Stepan Mishura
Intel Middleware Products Division


On 3/11/06, 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.
>
> 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