Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 202.81.18.152 is neither permitted nor
 denied by domain of paulex.yang@gmail.com)
Message-ID: <4416A6AB.9090201@gmail.com>
Date: Tue, 14 Mar 2006 19:19:07 +0800
From: Paulex Yang <paulex.yang@gmail.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: How to deal with this kind of serialization compatibility issue?
References: <176117377.1141718258821.JavaMail.jira@ajax>
	 <440D3FD9.3060000@gmail.com>
 <440D6A11.20106@googlemail.com>	 <906dd82e0603070337r45239913h@mail.gmail.com>
	 <440D743B.6010306@googlemail.com>
	 <906dd82e0603070426i5c23890di@mail.gmail.com>	 <440D8CF2.4030304@pobox.com>
	 <906dd82e0603070628n7578952dh@mail.gmail.com>	 <440E91F5.6020406@gmail.com>
 <44106708.2000406@googlemail.com>
 <906dd82e0603100109r4f50bae0l@mail.gmail.com>
In-Reply-To: <906dd82e0603100109r4f50bae0l@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Mikhail

I spent a little time on the framework, and I must say that this 
framework is very easy to use. Impressive!

But I still have some thoughts on it:
1. Sometime assertEquals() is not enough for the deserialized objects, 
i.e., if the predefined constants is serialized first by JRE instance A 
and deserialized later on  JRE instance B,  it should has same object 
identity with the existing constants in B, for example, the Locale.CHINA 
should be unique in any JRE instance. So it will be perfect if some 
helper method like assertSame() is provided.

It is also worth mentioning that some other time assertEquals() is too 
strict, because some serializable class may not override j.l.Object's 
equals(), so that the assertEquals() is equivalent to assertSame(), and 
it may not necessary.

2. I have some concerns on the abstract-class mode of SerializationTest, 
i.e., if some test want to leverage it, it must subclass this abstract 
class at first. What to do if it needs to inherited other abstract test 
cases, say, PerformanceTest?  So personally I prefer the less 
"intrusive" way like utility class. Another option is make the test case 
implements an interface with getData(), say ISerializationTest, and pass 
an instance of this interface to the utility class(similar with command 
pattern).

btw, I noticed there is also a serialization test utility class in the 
Harmony-57 contribution. The class is located in 
Harmon_Tests/src.helper/tests/util with name SerializationTester.java. 
It is a helper class which only providing some handy utility methods. 
But seems it lacks of adaptability to generate "GoldenFile" by reading 
configuration and not well documented.

What I suggest is to merge the two classes in some way, so that the 
whole class library test suites can leverage the benefits of unified 
serialization test framework/utility/anything.

thoughts?

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?
>
> Thanks,
> Mikhail
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM