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:53:01 GMT
Mikhail

Mikhail Loenko wrote:
> Hi Paulex,
>
> 2006/3/15, Paulex Yang <paulex.yang@gmail.com>:
>   
>> 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.
>>     
>
> Actually framework calls assertDeserialized() who in its turn by default
> calls assertEquals().
>
> For each specific test an author may override assertDeserialized() by
> something like you call assertSame(). Please have a look at an example:
>
> modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
>   
OK, I'm fine with this solution.
>   
>>>> 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.
>>     
>
> That is what we have now in security module:
>
> modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
> and
> modules/security/test/common/unit/java/security/CodeSignerTest.java
>
> Thanks,
> Mikhail
>   
That's great.
>
>   
>>>> 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
>>
>>
>>
>>     
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM



Mime
View raw message