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.
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.
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
