harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [classlib] Tests for serialization – which package, name?
Date Fri, 28 Apr 2006 07:32:33 GMT
Anton Avtamonov wrote:
> On 4/28/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
>   
>> On 4/27/06, Anton Avtamonov  wrote:
>>
>>     
>>> On 4/27/06, Tim Ellison wrote:
>>>       
>>>> I say leave them mixed.  We are no more likely to want to run
>>>> serialization tests separately than we are locking tests etc. and trying
>>>> to layout the tests on disk to represent all the different metadata
>>>> about each test case is not going to work.
>>>>         
>>> +1. usually we have test layout like: one class - one TestCase. I
>>> don't see big reason to support several layouts simultaneously
>>> (class-based, serialization-based, etc.)
>>>       
>> Agree, "one class - one TestCase" it's a good formula in general.
>> But I'd prefer separate tests to verify standalone functionality (BTW, there
>> a separate spec. for serialization!).
>>     
>
> Well, the spec describes how and which private fields/methods can be
> defined to handle serialization, right? So, to test serialization spec
> we should use special tests which cover serialization engine itself.
> As I told already that is not a case for object serialization testing
> which just ensure that object is properly restored.
>
>   
Agree. And we do not see any chances to just execute all of the 
serialization tests, shall we? ;-)
>> Separating makes possible to unify
>> testing approach that in turn leads to more simple and effective tests, for
>> example, which tests looks better?
>>
>> public class SerMyTest extends SerializationTest {
>>    protected Object[] getData() {
>>        return new Object[]{
>>            new My(param1, param2, param3),
>>             new My(param4, param5, param6),
>>            new My(param7, param8, param9),
>>        };
>>    }
>>
>>    protected void assertDeserialized(Object oref, Object otest) {
>>        //override to provide specific comparison
>>    }
>> }
>>
>> public class MyTest extends TestCase {
>>
>>    public void setUp() throws Exception {
>>        // sophisticated set up that unrelated to serialization at all !!!
>>    }
>>     public void tearDown() throws Exception {
>>        // sophisticated tear down that unrelated to serialization at all
>> !!!
>>    }
>>
>>     public void testSerialization1(){
>>        ObjectInputStream in = new
>> ObjectInputStream(getClass().getResourceAsStream(
>>                "test1.ser"));
>>        My my = (My) in.readObject();
>>        assertEquals(new My(param1, param2, param3), my);
>>     }
>>
>>     public void testSomethingUnrelatedToSerialization() {
>>     }
>>
>>     public void testSerialization2(){
>>        ObjectInputStream in = new
>> ObjectInputStream(getClass().getResourceAsStream(
>>                "test2.ser"));
>>        My my = (My) in.readObject();
>>        assertEquals(new My(param4, param5, param6), my);
>>     }
>>
>>     public void testCtor() {
>>     }
>>
>>     public void testSerialization3(){
>>        ObjectInputStream in = new
>> ObjectInputStream(getClass().getResourceAsStream(
>>                "test3.ser"));
>>        My my = (My) in.readObject();
>>        assertEquals(new My(param7, param8, param9), my);
>>     }
>> }
>>     
>
>
> Which approach is better is very personal :-). I would ay that the
> second one. It is more intention-revealing. Really, when you override
> testDeserialized() you don't see how and where it is used. With
> properly used delegation pattern the tests would be:
>
> testSelfSerialization() {
>     Object deserialized = SerializationTest.serializeDeserialize(original);
>     assertEquals(original, deserialized);
> }
>
> In case deserialization assertion for the particular object is not
> just assertEquals() it will be well-shown.
>
> Similarly to test against stored serialization form (golden file).
>
> Wishes,
> --
> 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
>
>
>   


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