harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [Fwd: Re: [classlib] Tests for serialization – which package, name?]
Date Fri, 28 Apr 2006 06:33:57 GMT
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?

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


Mime
View raw message