Stepan,

Cool! Basically I'm fine with the merging plan, and I'm very interested in more details, please see my comments below:

Stepan Mishura wrote:
Hi,

I'm going to start merging existing frameworks for testing serialization.

As first step I've updated 'security' framework. The updated framework
searches and loads resource files according [1] and eliminates requirement to extend SerializationTest. Also to provide smooth frameworks merging I've
put stub to let the framework search resources in the 'old' way (i.e. via
"RESOURCE_DIR" system property). The stub will be removed after completing
the merge.

The updated framework suggests the following way for testing serialization:

a) Compatibility – 4 new static methods are introduced.
   verifyGolden(TestCase, Object)
I suppose the TestCase is used to locate the golden file, i.e. BlablaTest will load BlablaTest.golden.ser?
   verifyGolden(TestCase, Object, SerializableAssert)
Is the SerializableAssert a command object? Does it currently exist? if not, what will it look like?
   verifyGolden(TestCase, Object[])
   verifyGolden(TestCase, Object[], SerializableAssert)
What's the meaning of Object[]? I guess the Object[i] is compared with XXXXTest.golden.1.ser?

A test should invoke one of above methods, for example,
public void testCompatibility() throws Exception {
   SerializationTest.verifyGolden(this, new SomeSerializableClass ());
}

b) Self-testing: the same as for compatibility – there are 4 new static
methods that should be invoked from a test:
   verifySelf(TestCase, Object)
   verifySelf(Object, SerializableAssert)
   verifySelf(TestCase, Object[])
   verifySelf(Object[], SerializableAssert)
What's the difference between methods with and without TestCase? Does this imply if it needs to find persistent serialization files? And why the methods with TestCase parameter don't need customized SerializationAssert?

For example,
public void testSelf() throws Exception {
   SerializationTest.verifySelf(new SomeSerializableClass(), new
MyComparator());
}

To complete frameworks merging I'd like to suggest the next steps:
2) Reviewing the update and the suggested way for testing serialization by
the community. Please let me know if it is acceptable and what can be
improved.
3) Replace SerializationTester class with SerializationTest. I'm going to
add more stubs to let existing tests work in the 'old' way.
4) Adjusting existing serialization tests (moving and renaming resource
files, replacing stubs invocation with new methods)
5) Removing stubs.
Thank you, Stepan, it is a really good plan!

Thanks,
Stepan Mishura
Intel Middleware Products Division

[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html

------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Paulex Yang
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]

Reply via email to