Anton Avtamonov wrote:
On 4/28/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 4/27/06, Anton Avtamonov wrote:
On 4/27/06, Tim Ellison wrote:
I say leave them mixed. We are no more likely to want to run
serialization tests separately than we are locking tests etc. and trying
to layout the tests on disk to represent all the different metadata
about each test case is not going to work.
+1. usually we have test layout like: one class - one TestCase. I
don't see big reason to support several layouts simultaneously
(class-based, serialization-based, etc.)
Agree, "one class - one TestCase" it's a good formula in general.
But I'd prefer separate tests to verify standalone functionality (BTW, there
a separate spec. for serialization!).
Well, the spec describes how and which private fields/methods can be
defined to handle serialization, right? So, to test serialization spec
we should use special tests which cover serialization engine itself.
As I told already that is not a case for object serialization testing
which just ensure that object is properly restored.
Agree. And we do not see any chances to just execute all of the
serialization tests, shall we? ;-)
Separating makes possible to unify
testing approach that in turn leads to more simple and effective tests, for
example, which tests looks better?
public class SerMyTest extends SerializationTest {
protected Object[] getData() {
return new Object[]{
new My(param1, param2, param3),
new My(param4, param5, param6),
new My(param7, param8, param9),
};
}
protected void assertDeserialized(Object oref, Object otest) {
//override to provide specific comparison
}
}
public class MyTest extends TestCase {
public void setUp() throws Exception {
// sophisticated set up that unrelated to serialization at all !!!
}
public void tearDown() throws Exception {
// sophisticated tear down that unrelated to serialization at all
!!!
}
public void testSerialization1(){
ObjectInputStream in = new
ObjectInputStream(getClass().getResourceAsStream(
"test1.ser"));
My my = (My) in.readObject();
assertEquals(new My(param1, param2, param3), my);
}
public void testSomethingUnrelatedToSerialization() {
}
public void testSerialization2(){
ObjectInputStream in = new
ObjectInputStream(getClass().getResourceAsStream(
"test2.ser"));
My my = (My) in.readObject();
assertEquals(new My(param4, param5, param6), my);
}
public void testCtor() {
}
public void testSerialization3(){
ObjectInputStream in = new
ObjectInputStream(getClass().getResourceAsStream(
"test3.ser"));
My my = (My) in.readObject();
assertEquals(new My(param7, param8, param9), my);
}
}
Which approach is better is very personal :-). I would ay that the
second one. It is more intention-revealing. Really, when you override
testDeserialized() you don't see how and where it is used. With
properly used delegation pattern the tests would be:
testSelfSerialization() {
Object deserialized = SerializationTest.serializeDeserialize(original);
assertEquals(original, deserialized);
}
In case deserialization assertion for the particular object is not
just assertEquals() it will be well-shown.
Similarly to test against stored serialization form (golden file).
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
