harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Avtamonov" <anton.avtamo...@gmail.com>
Subject Re: [classlib] Tests for serialization – which package, name?
Date Fri, 28 Apr 2006 06:11:10 GMT
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.

> 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


Mime
View raw message