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: [Fwd: Re: [classlib] Tests for serialization – which package, name?]
Date Fri, 28 Apr 2006 07:33:56 GMT
Paulex Yang wrote:
> Mikhail Loenko wrote:
>> 2006/4/28, Paulex Yang <paulex.yang@gmail.com>:
>>  
>>> Anton Avtamonov wrote:
>>>
>>>    
>>>> On 4/27/06, Mikhail Loenko <mloenko@gmail.com> wrote:
>>>>
>>>>      
>>>>> As far as most of serialization tests extend SerializationTest then
>>>>> having serialization test cases included into a regular unit tests
>>>>> would cause that ALL the tests will extend SerializationTest that is
>>>>> not very good.
>>>>>
>>>>>         
>>>> Well, it is easy to allow serialization tests to be in the same
>>>> TestCase with others.
>>>> We just need to convert the existing schema with inheritance to the
>>>> delegation pattern. Or combine both approaches by adding public static
>>>> method to the SerializationTest which gets an Object and returns an
>>>> Object which were serialized and deserialized (similar to testSelf()
>>>> but without assertion). And public static accessor to golden files of
>>>> course.
>>>> May be it even make the tests more obvious:
>>>>
>>>> Object deserialized = 
>>>> SerializationTest.serializeAndDeserialize(original);
>>>> assertEquals(original, deserialzied);
>>>>
>>>>       
>>> FYI.
>>>
>>> This is the idea of another serialization tester, it provides several
>>> similar utility methods. You may be interested to refer to [1] for 
>>> details.
>>>
>>> And its typical use scenario can be found in test_serialization() and
>>> test_serializationCompatibility() methods in [2].
>>>
>>> In fact test_Serialization() can be more concise to only includes one
>>> statement like below:
>>>
>>> public void test_Serialization() throws Exception{
>>>   assertTrue(SerializationTester.assertEquals(new SomeSerializable()));
>>> }
>>>
>>> it will serialize given object to byte array, deserialize to another
>>> object, compare them and return result.
>>>     
>>
>> How will this test catch missing or extra field in the serialization 
>> form?
>>   
> I think two serialization test is necessary in general:
>
> 1. test for Harmony itself, which ensure that the object can be 
> serialized/deserialized smoothly within Harmony VM/classlib
> 2. test for compatibility with RI, which ensure that the object 
> serialized by RI can be deserialized by Harmony smoothly, and vice versa.
>
> The sample I mentioned is only for case 1. And if I understand you 
> clearly, your concern is about case 2, for which, there is a 
> test_serializationCompatibility() method in [2].
>
> And the SerializationTester[1] provide a helper method named as 
> assertCompabilityEquals(Object obj, String fileName), which will 
> deserialize object from give file (supposing it's the golden file 
> generated by RI), compare with given Object and return result.
I missed one thing just now, because currently we only run testcases on 
Harmony, currently these testcass only cover half of case 2 - 
deserialized bytes generated by RI in Harmony. And if we start to run 
testcase on RI someday, we can try some straight forward modification to 
support the other part.
>
>> Thanks,
>> Mikhail
>>
>>
>>  
>>> [1]
>>> http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/util/SerializationTester.java?rev=386058&view=log

>>>
>>> [2]
>>> http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/util/IllegalFormatCodePointExceptionTest.java?rev=396023&view=markup

>>>
>>>
>>>    
>>>> I don't think that having ser tests separated is a bad idea, however
>>>> having an additinal test file with one-two methods only for each api
>>>> class looks like a bit 'expensive' approach.
>>>>
>>>>
>>>>      
>>>>> Thanks,
>>>>> Mikhail
>>>>>
>>>>> 2006/4/27, Stepan Mishura <stepan.mishura@gmail.com>:
>>>>>
>>>>>        
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to discuss naming conventions for serialization tests -

>>>>>> does it
>>>>>> make sense to separate serialization tests from unit tests?
>>>>>>
>>>>>> For example, in module security tests for serialization were 
>>>>>> placed into
>>>>>> separate packages:
>>>>>> java.security.serialization
>>>>>> java.security.cert.serialization
>>>>>> java.security.spec.serialization
>>>>>>
>>>>>> Also it is possible to put tests in the same package but name 
>>>>>> them in
>>>>>> different ways, for example,
>>>>>> SomeClassTest.java – unit test for SomeClass
>>>>>> SerSomeClassTest.java – serialization test for SomeClass
>>>>>>
>>>>>> Or we won't separate serialization tests from unit tests and will

>>>>>> test
>>>>>> serialization by adding corresponding methods to unit test, for 
>>>>>> example,
>>>>>> public void testSerialization1()
>>>>>> public void testSerialization2()
>>>>>> public void testSerialization3()
>>>>>> public void testSerializationCorrupted()
>>>>>> public void testSerializationIllegalValues()
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Thanks,
>>>>>> Stepan Mishura
>>>>>> Intel Middleware Products Division
>>>>>>
>>>>>> ------------------------------------------------------
>>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: 
>>>>>> harmony-dev-help@incubator.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>           
>>>>> ---------------------------------------------------------------------
>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: 
>>>>> harmony-dev-help@incubator.apache.org
>>>>>
>>>>>
>>>>>
>>>>>         
>>>> -- 
>>>> Anton Avtamonov,
>>>> Intel Middleware Products Division
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>>>
>>>>       
>>> -- 
>>> Paulex Yang
>>> China Software Development Lab
>>> IBM
>>>
>>>
>>>
>>>
>>> -- 
>>> Paulex Yang
>>> China Software Development Lab
>>> IBM
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>     
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>>   
>
>


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message