On 6/26/06, Paulex Yang wrote:
Stepan,
Thank you for the answer, the updated version on the website is fine,
only one issue:
About this method:
|verifyGolden(TestCase, Object[], SerializableAssert)
Do we need to add the SerializableAssert's definition on that page? (I
suppose it is an interface or so?)
Yes, it is an interface. I agree that it makes sense to add definition of
the interface - done in r417165, please review.
Thanks,
Stepan.
|
Stepan Mishura wrote:
> 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]
>
--
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]
--
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]
