harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib] Merging frameworks for testing serialization - first step
Date Mon, 26 Jun 2006 08:41:58 GMT
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?)
|
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message