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