harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [classlib] Merging frameworks for testing serialization - first step
Date Tue, 20 Jun 2006 10:00:39 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message