harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Tue, 14 Mar 2006 12:14:09 GMT
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.java)
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 have
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/SerializationTest.java
> >
> > It serves to simplify serialization testing and has the docs inside. Actually
> > almost all serializable security-related classes are tested with this framework.
> >
> > Does it make sense to move the framework to a common place?
> >
> > Thanks,
> > Mikhail
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>

Mime
View raw message