Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates
 66.249.92.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ulvKHj2xRui2r007npv7r/249qZ2nunpWZ9PGs2MtWLgzzIlXvjDNzwz9ObAUxMxxP9w4SFM6rEgpy2QnYIe5uPOWpGs3NH9k5OAlA6B8tXt4KMBRR+nXBADXzHoy1VzCEcRC946mxzJXM+Sps9XbFm8hw/IEz/ZIwuYVhBeNR8=
Message-ID: <906dd82e0603140414x300c2787l@mail.gmail.com>
Date: Tue, 14 Mar 2006 18:14:09 +0600
From: "Mikhail Loenko" <mloenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: How to deal with this kind of serialization compatibility issue?
In-Reply-To: <4416A6AB.9090201@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <176117377.1141718258821.JavaMail.jira@ajax>
	 <906dd82e0603070337r45239913h@mail.gmail.com>
	 <440D743B.6010306@googlemail.com>
	 <906dd82e0603070426i5c23890di@mail.gmail.com>
	 <440D8CF2.4030304@pobox.com>
	 <906dd82e0603070628n7578952dh@mail.gmail.com>
	 <440E91F5.6020406@gmail.com> <44106708.2000406@googlemail.com>
	 <906dd82e0603100109r4f50bae0l@mail.gmail.com>
	 <4416A6AB.9090201@gmail.com>

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.ja=
va)
do you mean something like that?

>
> 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 h=
ave
to care about them.

>
> 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/Seri=
alizationTest.java
> >
> > It serves to simplify serialization testing and has the docs inside. Ac=
tually
> > almost all serializable security-related classes are tested with this f=
ramework.
> >
> > Does it make sense to move the framework to a common place?
> >
> > Thanks,
> > Mikhail
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>