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
