Hi Paulex,
see answers below
On 6/20/06, Paulex Yang wrote:
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?
Right, it is used to locate the golden file.
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?
Right again. So if you have one object to be verified you will use
verifyGolden(TestCase, Object) and if there are several objects to be
tested
then you may wish to use verifyGolden(TestCase, Object[]).
> 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?
The difference is quite simple: in case of TestCase the framework
looks up
for an appropriate SerializationAssert. In other words, it is equivalent:
verifySelf(object, defineComparator(test, object));
May be methods with TestCase param are little bit confusing - it is
possible
to remove them.
Does this imply if it needs to find persistent serialization files?
No, it doesn't.
And why the methods with TestCase parameter don't need
customized SerializationAssert?
As I wrote above the framework tries to figure out an appropriate
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!
Thank you for your feedback.
- Stepan
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
