harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Wed, 15 Mar 2006 10:21:08 GMT
Hi, Mikhail,

Mikhail Loenko wrote:
> Hi Paulex,
>
> 2006/3/14, Paulex Yang <paulex.yang@gmail.com>:
>   
>> 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.
>>     
>
> There is assertDeserialized() method in the framework (SerializationTest.java)
> do you mean something like that?
>
>   
Yes, something like that, but invoke assertSame() instead of 
assertEquals(), or switch case by some configuration.
>> 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).
>>     
>
> SerializationTest.java has bodies of two test methods:
>     testSelf()
>     testGolden()
>
> These methods are inherited and called by JUnit, so test developer do not have
> to care about them.
>
>   
Sure, that's the advantages of abstract class mode, but the utility 
class is more *flexible*, i.e. less "intrusive" to the concrete test 
classes.

Maybe there is another way to achieve both convenience and flexibility, 
by separate test case for serialization to  a single file, say ,
for:
public  class AClass implements Serializable{...}

we have:
AClassTest, for common test cases,
and
AClassSerializationTest extends SerializationTest, for serialization test.
>> 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.
>>     
>
> I need to study H-57 SerializationTester, likely it makes sense taking
> best ideas from both
>
> Thanks,
> Mikhail.
>
>   
>> 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
>>
>>
>>
>>     
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM



Mime
View raw message