Mikhail, You are right - I think I asked not proper question. The base issue is: how we are going to test serialization and what support from testing framework is required? So far we have two serialization frameworks. Roughly, the first framework provides utility class with set of static methods and the second one provides super class to be extended.
Let's understand what kind of serialization tests are required. 1) Compatibility: testing scenario - serialize a number of a class' objects on RI to get a set of golden files, create test to verify that deserialization of golden files produces expected objects on Harmony implementation. I think that everybody agree that this scenario is required for every serializable class. 2) Self testing: testing scenario is to verify that an object can be serialized/deserialized smoothly on Harmony implementation. Again this scenario is also required for every serializable class. 3) Error: testing scenario is to check that deserialization of corrupted serial form results in IOException, for example, if a class has fields startDate and endDate then class implementation should verify that startDate < endDate after deserialization. This scenario is not required for every class. Are there any others testing scenarios? I think that this is obvious that 1 and 2 scenarios need support from testing framework. Let's review what support we currently have: --- compatibility testing scenario: If you use the first framework then you have explicitly add to each test for serializable class a separate method and use utility methods to perform testing, for example, public void serializationCompatibility() { SerializationTester.assertCompabilityEquals(new MyClass(), " MyClassFile.ser"); } In case of the second framework a test inherits method testGolden() that does standart testing routine: for each object returned by getData() method it finds corresponding golden file, deserializes it and compares with the object. --- self testing scenario: Similar to compatibility scenario: using the first framework you have explicitly add a separate testing method: public void testSerialization() { assertTrue(SerializationTester.assertEquals(new SomeSerializable())); } In case of the second framework a test inherits testSelf() does the following testing routine: for each object returned by getData() method it serializes/deserializes the object and compares with the initial object. To summarize: for the first framework it is required to add explicitly at least two testing methods to each test. The second framework uses inheritance mechanism so two standart testing methods are inherited from super class and you only have to implement getData() abstract method. IMHO, as far as it is possible to unify serialization testing I think that inheritance appoach makes sense - two standart testing methods, less copied/pasted code that leads to more maintainable tests. Thoughts? Thanks, Stepan. On 4/28/06, Mikhail Loenko wrote:
I suggest that we first decide how we will test serialization, otherwise we may make a low-level decision that will make some high-level designs impossible Thanks, Mikhail <SNIP>
-- Thanks, Stepan Mishura 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]