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.
Yes, George. That's make sense :-)
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
I think that separating out all test artefacts from actual source code
is cleaner and IMHO makes the maintenance easier :-)
I think there is no big difference. But anyway we shall agree with one
of the three options.
1) Put test data files into a separated folder, and use the package name
of test case as its namespace.
e.g., <MODULE_ROOT>/src/test/resources/serialization/tests/api/java/util
2) Put test data files into a separated folder, and use the package
name of the class under test as its namespace.
e.g.
<MODULE_ROOT>/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
3. Put test data files into the same location as the test case.
Shall we vote? :-)
Using either Ant or <IDE of choice> it is pretty straightforward to
get these resources placed on the classpath when the tests are run.
Yes. I think we all agree with this.
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
--
Richard Liang
China Software Development Lab, IBM
