harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Fri, 10 Mar 2006 19:20:08 GMT
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.

protected File getDataFile(int index) {
    String name = "/" + this.getClass().getName().replace('.', '/') + "."
        + index + ".dat";
    return new 

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

View raw message