harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Tue, 14 Mar 2006 11:49:13 GMT
Paulex Yang wrote:
> 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.
> 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).
> 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.
> thoughts?

Hi Paulex,

I was aware that the HARMONY-57 archive contained equivalent 
functionality but, revisiting it just now, had forgotten just how 
similar the two utilities are. IMHO there is definitely *lots* to be 
taken from both approaches if we move towards a unified approach.

* From a Java language perspective, I like the fact that the HARMONY-57 
SerializationTester does not mandate other test classes to extend it. 
But, on the other hand, having that functionality encapsulated in static 
helper methods belonging to another type does not force test developers 
to actually use it. So, from a "force people to think about 
serialization when writing their tests !!" perspective, the security 
module's approach of mandating classes extend their abstract 
SerializationTest is kind of appealing. OK, I am being totally 
schizophrenic here. Your idea of an interface that test classes of 
Serializable types should implement sounds like a good way forwards here.

* I like the way that the HARMONY-57 SerializationTester checks on 
predefined constant objects being the same.

* It's good that the security module's code encourages more than one 
.ser/.dat file to be produced for testing a wide range of object states.

* I like the security module code's template method 
assertDeserialization() that enables test code to have a means of 
checking the success of the serialization/deserialization functionality 
customised for the specific type under test.

What still bothers me is the fact that developers can't be forced to 
implement any notional ISerializationTest interface nor extend any 
abstract SerializationTest class in a unit test class that tests out a 
Serializable type. But that's a whole different story altogether...

Best regards,

> 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

View raw message