Hi Paulex,
2006/3/15, Paulex Yang <[EMAIL PROTECTED]>:
> Hi, Mikhail,
>
> Mikhail Loenko wrote:
> > Hi Paulex,
> >
> > 2006/3/14, Paulex Yang <[EMAIL PROTECTED]>:
> >
> >> 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?
> >
> >
> Yes, something like that, but invoke assertSame() instead of
> assertEquals(), or switch case by some configuration.
Actually framework calls assertDeserialized() who in its turn by default
calls assertEquals().
For each specific test an author may override assertDeserialized() by
something like you call assertSame(). Please have a look at an example:
modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
> >> 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.
> >
> >
> Sure, that's the advantages of abstract class mode, but the utility
> class is more *flexible*, i.e. less "intrusive" to the concrete test
> classes.
>
> Maybe there is another way to achieve both convenience and flexibility,
> by separate test case for serialization to a single file, say ,
> for:
> public class AClass implements Serializable{...}
>
> we have:
> AClassTest, for common test cases,
> and
> AClassSerializationTest extends SerializationTest, for serialization test.
That is what we have now in security module:
modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
and
modules/security/test/common/unit/java/security/CodeSignerTest.java
Thanks,
Mikhail
> >> 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 <[EMAIL PROTECTED]>:
> >>> ...
> >>>
> >>>
> >>>> 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
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
