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.
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
