You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stepan Mishura <st...@gmail.com> on 2006/06/20 10:11:04 UTC
[classlib] Merging frameworks for testing serialization - first step
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)
verifyGolden(TestCase, Object, SerializableAssert)
verifyGolden(TestCase, Object[])
verifyGolden(TestCase, Object[], SerializableAssert)
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)
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.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] trying new framework for testing serialization
Posted by Stepan Mishura <st...@gmail.com>.
Anton,
You suggestion works only if a test extends SerializationTest but we agree
avoid this (i.e. a test should invoke only static utility methods of
SerializationTest)
Thanks,
Stepan.
On 7/7/06, Anton Luht wrote:
>
> Stepan,
>
> I think that there's no need in SerializableAssert interface - just
> put assertDeserialized(Serializable, Serializable) method to
> SerializationTest class with default implementation based on current
> code from defineComparator (if there's equals(), use it, if it's
> instance of Throwable, use some other scheme, etc). If a developer
> needs his own comparing method, he just redefines this method. If he's
> happy with equals(), he does nothing.
>
> So, verifySelf will look like:
>
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> putObjectToStream(object, out);
> ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray());
> assertDeserialized((Serializable) object, (Serializable)
> getObjectFromStream(in));
>
> This will help us remove methods with SerializableAsset as a third
> parameter.
>
> And a small note: we don't need flush() before close() :)
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
>
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> 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
Re: [classlib] trying new framework for testing serialization
Posted by Anton Luht <an...@gmail.com>.
Stepan,
I think that there's no need in SerializableAssert interface - just
put assertDeserialized(Serializable, Serializable) method to
SerializationTest class with default implementation based on current
code from defineComparator (if there's equals(), use it, if it's
instance of Throwable, use some other scheme, etc). If a developer
needs his own comparing method, he just redefines this method. If he's
happy with equals(), he does nothing.
So, verifySelf will look like:
ByteArrayOutputStream out = new ByteArrayOutputStream();
putObjectToStream(object, out);
ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray());
assertDeserialized((Serializable) object, (Serializable)
getObjectFromStream(in));
This will help us remove methods with SerializableAsset as a third parameter.
And a small note: we don't need flush() before close() :)
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
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
RE: [classlib] trying new framework for testing serialization
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Stepan Mishura [mailto:stepan.mishura@gmail.com]
>
> * When loading the resource, the name is assembled using
> File.separatorChar
> > as the separator, but you should just be using the character "/" since
> > that's the normative class path separator.
>
> I didn't catch what the problem with File.separatorChar.
>
The field java.io.File.separatorChar varies from platform to platform "\" on
windows, "/" on Unix/Linux/etc and is intended for file system use. The
resource paths of a class loader use the separator "/"; it doesn't vary by
platform. The ClassLoader is probably being agreeable and letting this code
get away with it, but it's not required to.
-Nathan
---------------------------------------------------------------------
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
Re: [classlib] trying new framework for testing serialization
Posted by Stepan Mishura <st...@gmail.com>.
Hi Nathan,
On 7/6/06, Nathan Beyer wrote:
>
> I have a couple comments on the code and guidelines after working with
> them
> for a little bit.
>
> * Do we need the "serialization" package prefix? I'd prefer to just have
> the
> resource be in the same folder/package as of the test case. The files are
> already separated into a "resource" folder.
No, we don't. The "serialization" package prefix shouldn't be used - we
agreed that we don't separate serialization tests from unit tests. The
prefix comes from the initial contribution (HARMONY-16).
* It seems a little awkward, or at least not immediately apparent that a
> file name after the test case is a serialized instance of an object. For
> example, "UUIDTest.golden.ser" would be an instance of the class UUID. My
> suggestion would be to take the Class object as an additional parameter
> and
> then use the following algorithm to build the path:
> '(testCaseInst.getClass().getPackage() + "/" +
> clazz.getSimpleName()).replaceAll('.','/')'. Note: getSimpleName may not
> be
> implemented yet, but you can subtract the package name from the full name.
The point is to identify by a resource name a test where the resource is
used, for example, we may have UUIDTest1 and UUIDTest2.
* When loading the resource, the name is assembled using File.separatorChar
> as the separator, but you should just be using the character "/" since
> that's the normative class path separator.
I didn't catch what the problem with File.separatorChar.
* Currently, the System ClassLoader is used, which we can probably get away
> with for now, but I would suggest using the ClassLoader of the TestCase
> passed. If the System ClassLoader is needed, it will be delegated down to
> it
> eventually.
Yes, it is possible to use the ClassLoader of the passed TestCase. There
will be only one minor restriction. Tests for serialization can not be
located on the bootclasspath because resource files are located on the
classpath. But currently we have a number of serialization tests are running
on the bootclasspath, for example, in security module. So we should
refractor these tests first to run them from the classpath.
* Why do all of the methods of SerializationTest start with 'verify' instead
> of 'assert'? This seems awkward and inconsistent with JUnit practices.
Yes, I also thought about starting with 'assert'. But it looked for me at
that time a little bit confusing. Now it seems that starting with 'assert'
looks more natural. So we will have methods 'assertGolden' and 'assertSelf'.
However in this case I'd change 'assertSelf' to something like
'assertSerializableObject'. Other suggestions?
* Why does SerializationTest extend TestCase? I suggest separating the
> assertion methods and the abstract TestCase functionality and remove the
> artificial coupling.
This also comes from the initial contribution (HARMONY-16) - the idea was to
unify serialization testing using inheritance so we have separate
serialization tests in 4 module that extend super-test
class(SerializationTest). But we agreed that we wouldn't test serialization
in that way - so you should avoid extending SerializationTest and create
new serialization tests according to the guidelines [1].
* In all of the places where "TestCase.assertXXX" is used, I would suggest
> using "Assert.assertXXX", as this is the class that defines these methods.
> TestCase just extends Assert to simplify the usage of the 'assertXXX'
> methods for normal test classes.
Agree.
Thanks for you comments,
Stepan.
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
-Nathan
>
> > -----Original Message-----
> > From: Stepan Mishura [mailto:stepan.mishura@gmail.com]
> > Sent: Wednesday, July 05, 2006 3:08 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [classlib] trying new framework for testing serialization
> >
> > Hi Andrew,
> >
> > On 7/3/06, Andrew Zhang wrote:
> > >
> > > Hi Stepan,
> > >
> > > I tried serialization test framework, and found it's really easy to
> use.
> > > :)
> > >
> > > Here I have a small question: why TestCase is designed as first
> > parameter?
> >
> >
> > Because it is required for all methods for testing compatibility so I
> made
> > it as first parameter.
> >
> > > If I understand correctly, it's used to parse exception name.
> >
> > No, it is not. It is used to locate resource files only. For example,
> > TestCase:
> > org.apache.harmony.luni.tests.java.lang.SomeClassTest
> > Resource:
> > org/apache/harmony/luni/tests/java/lang/SomeClassTest.golden.ser
> >
> > So is it the
> > > same if we simply pass the String or Class of the object to
> > > SerializationTest?
> >
> >
> > Do you mean Class of TestCase or an object to be tested?
> >
> > Maybe it's a tradeoff for highly automated, still I think pass String or
> > > Class is not a big deal for user.
> > >
> > > Did I miss something? Or TestCase is used for other reasons?
> >
> >
> > It is used to locate resource files only.
> >
> > Thanks,
> > Stepan.
> >
> > >
> > >
> > >
> > >
> > > On 6/30/06, Stepan Mishura wrote:
> > > >
> > > > On 6/30/06, Jimmy, Jing Lv wrote:
> > > > >
> > > > > Stepan Mishura wrote:
> > > > > > Hi Jimmy,
> > > > > >
> > > > > <SNIP>
> > > > > > 3. The test needs ser-files, so it may be necessary to add a
> > method
> > > to
> > > > > >> create this file easily just like the old framework. I find a
> > > > protected
> > > > > >> method produceGoldenFiles(), is that used for it (why
> > protected?)?
> > > > This
> > > > > >> may be necessary to guildance.
> > > > > >> What's more, the ser-file must be end with ".ser", but in new
> > > > > framework,
> > > > > >> I still find it uses ".dat" . And the path is
> > > "test/common/unit/..."
> > > > > but
> > > > > >> in Harmony's Test Guildance
> > > > > tells:"/src/test/resources/serialization..."
> > > > > >
> > > > > >
> > > > > > Yes, I agree that utility method for producing golden files will
> > be
> > > > > useful.
> > > > > > I didn't think how to implement it yet - so suggestion and
> patches
> > > are
> > > > > > welcome.
> > > > > >
> > > > >
> > > > > I see now, thank you very much Stepan! :)
> > > > > To produce golden files, I believe a little change to
> > > > > produceGoldenFiles() may meet this requirement. I'd like to
> help.:)
> > > >
> > > >
> > > > Great!
> > > >
> > > > But first of all it may change its search path, as when I create a
> new
> > > > > test and try verifyGolden(), I find a FileNotFoundException. It
> > seems
> > > > > trying to search "test/common/unit/.../SomeTest.golden.dat", is
> that
> > > > > because of serialization-test for security? Waiting for your
> > > refactoring
> > > > > :)
> > > > >
> > > > >
> > > > >
> > > > > Currently the framework search resource files in the next order:
> > > > it tries to load a resource file from the classpath (resource file
> > name
> > > > should follow new conventions); if it failed then it loads it in
> 'old'
> > > way
> > > > (
> > > > i.e. using RESOURCE_DIR system property). The 'old' way will be
> > removed
> > > > after completing 'security' tests migration.
> > > >
> > > > If you see FileNotFoundException then it means that the framework
> can
> > > find
> > > > resource file on the classpath. Please check that:
> > > > 1) a resource file follows new naming conventions
> > > > 2) a resource file is on the classpath
> > > >
> > > > BTW, I've refactored one security test[1]. You may wish to use it as
> > > > example.
> > > >
> > > > Thanks,
> > > > Stepan Mishura
> > > >
> > > > P.S.
> > > > I'll have random access to e-mail starting next week. Please expect
> > some
> > > > delay in response.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mod
> >
> ules/security/src/test/api/java/org/apache/harmony/security/tests/java/sec
> > urity/serialization/KeyPairTest.java?revision=418191&view=markup
> > > >
> > > > ------------------------------------------------------
> > > > 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
> > > >
> > > >
> > >
> > >
> > > --
> > > Andrew Zhang
> > > China Software Development Lab, IBM
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] trying new framework for testing serialization
Posted by Andrew Zhang <zh...@gmail.com>.
Hello Stepan,
Thanks for your explanation.
It seems I have to wait until NIO test package layout is complete.
The test package structure is not the same as SerializationTest framework
expects.
I'll use merged serialization test framework then. :)
btw: Paulex said he'd like to do it in the previous thread.
Thanks.
On 7/5/06, Stepan Mishura <st...@gmail.com> wrote:
>
> Hi Andrew,
>
> On 7/3/06, Andrew Zhang wrote:
> >
> > Hi Stepan,
> >
> > I tried serialization test framework, and found it's really easy to use.
> > :)
> >
> > Here I have a small question: why TestCase is designed as first
> parameter?
>
>
> Because it is required for all methods for testing compatibility so I made
> it as first parameter.
>
> > If I understand correctly, it's used to parse exception name.
>
> No, it is not. It is used to locate resource files only. For example,
> TestCase:
> org.apache.harmony.luni.tests.java.lang.SomeClassTest
> Resource:
> org/apache/harmony/luni/tests/java/lang/SomeClassTest.golden.ser
>
> So is it the
> > same if we simply pass the String or Class of the object to
> > SerializationTest?
>
>
> Do you mean Class of TestCase or an object to be tested?
>
> Maybe it's a tradeoff for highly automated, still I think pass String or
> > Class is not a big deal for user.
> >
> > Did I miss something? Or TestCase is used for other reasons?
>
>
> It is used to locate resource files only.
>
> Thanks,
> Stepan.
>
> >
> >
> >
> >
> > On 6/30/06, Stepan Mishura wrote:
> > >
> > > On 6/30/06, Jimmy, Jing Lv wrote:
> > > >
> > > > Stepan Mishura wrote:
> > > > > Hi Jimmy,
> > > > >
> > > > <SNIP>
> > > > > 3. The test needs ser-files, so it may be necessary to add a
> method
> > to
> > > > >> create this file easily just like the old framework. I find a
> > > protected
> > > > >> method produceGoldenFiles(), is that used for it (why
> protected?)?
> > > This
> > > > >> may be necessary to guildance.
> > > > >> What's more, the ser-file must be end with ".ser", but in new
> > > > framework,
> > > > >> I still find it uses ".dat" . And the path is
> > "test/common/unit/..."
> > > > but
> > > > >> in Harmony's Test Guildance
> > > > tells:"/src/test/resources/serialization..."
> > > > >
> > > > >
> > > > > Yes, I agree that utility method for producing golden files will
> be
> > > > useful.
> > > > > I didn't think how to implement it yet - so suggestion and patches
> > are
> > > > > welcome.
> > > > >
> > > >
> > > > I see now, thank you very much Stepan! :)
> > > > To produce golden files, I believe a little change to
> > > > produceGoldenFiles() may meet this requirement. I'd like to help.:)
> > >
> > >
> > > Great!
> > >
> > > But first of all it may change its search path, as when I create a new
> > > > test and try verifyGolden(), I find a FileNotFoundException. It
> seems
> > > > trying to search "test/common/unit/.../SomeTest.golden.dat", is that
> > > > because of serialization-test for security? Waiting for your
> > refactoring
> > > > :)
> > > >
> > > >
> > > >
> > > > Currently the framework search resource files in the next order:
> > > it tries to load a resource file from the classpath (resource file
> name
> > > should follow new conventions); if it failed then it loads it in 'old'
> > way
> > > (
> > > i.e. using RESOURCE_DIR system property). The 'old' way will be
> removed
> > > after completing 'security' tests migration.
> > >
> > > If you see FileNotFoundException then it means that the framework can
> > find
> > > resource file on the classpath. Please check that:
> > > 1) a resource file follows new naming conventions
> > > 2) a resource file is on the classpath
> > >
> > > BTW, I've refactored one security test[1]. You may wish to use it as
> > > example.
> > >
> > > Thanks,
> > > Stepan Mishura
> > >
> > > P.S.
> > > I'll have random access to e-mail starting next week. Please expect
> some
> > > delay in response.
> > >
> > > [1]
> > >
> > >
> >
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/serialization/KeyPairTest.java?revision=418191&view=markup
> > >
> > > ------------------------------------------------------
> > > 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
> > >
> > >
> >
> >
> > --
> > Andrew Zhang
> > China Software Development Lab, IBM
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
RE: [classlib] trying new framework for testing serialization
Posted by Nathan Beyer <nb...@kc.rr.com>.
I have a couple comments on the code and guidelines after working with them
for a little bit.
* Do we need the "serialization" package prefix? I'd prefer to just have the
resource be in the same folder/package as of the test case. The files are
already separated into a "resource" folder.
* It seems a little awkward, or at least not immediately apparent that a
file name after the test case is a serialized instance of an object. For
example, "UUIDTest.golden.ser" would be an instance of the class UUID. My
suggestion would be to take the Class object as an additional parameter and
then use the following algorithm to build the path:
'(testCaseInst.getClass().getPackage() + "/" +
clazz.getSimpleName()).replaceAll('.','/')'. Note: getSimpleName may not be
implemented yet, but you can subtract the package name from the full name.
* When loading the resource, the name is assembled using File.separatorChar
as the separator, but you should just be using the character "/" since
that's the normative class path separator.
* Currently, the System ClassLoader is used, which we can probably get away
with for now, but I would suggest using the ClassLoader of the TestCase
passed. If the System ClassLoader is needed, it will be delegated down to it
eventually.
* Why do all of the methods of SerializationTest start with 'verify' instead
of 'assert'? This seems awkward and inconsistent with JUnit practices.
* Why does SerializationTest extend TestCase? I suggest separating the
assertion methods and the abstract TestCase functionality and remove the
artificial coupling.
* In all of the places where "TestCase.assertXXX" is used, I would suggest
using "Assert.assertXXX", as this is the class that defines these methods.
TestCase just extends Assert to simplify the usage of the 'assertXXX'
methods for normal test classes.
-Nathan
> -----Original Message-----
> From: Stepan Mishura [mailto:stepan.mishura@gmail.com]
> Sent: Wednesday, July 05, 2006 3:08 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib] trying new framework for testing serialization
>
> Hi Andrew,
>
> On 7/3/06, Andrew Zhang wrote:
> >
> > Hi Stepan,
> >
> > I tried serialization test framework, and found it's really easy to use.
> > :)
> >
> > Here I have a small question: why TestCase is designed as first
> parameter?
>
>
> Because it is required for all methods for testing compatibility so I made
> it as first parameter.
>
> > If I understand correctly, it's used to parse exception name.
>
> No, it is not. It is used to locate resource files only. For example,
> TestCase:
> org.apache.harmony.luni.tests.java.lang.SomeClassTest
> Resource:
> org/apache/harmony/luni/tests/java/lang/SomeClassTest.golden.ser
>
> So is it the
> > same if we simply pass the String or Class of the object to
> > SerializationTest?
>
>
> Do you mean Class of TestCase or an object to be tested?
>
> Maybe it's a tradeoff for highly automated, still I think pass String or
> > Class is not a big deal for user.
> >
> > Did I miss something? Or TestCase is used for other reasons?
>
>
> It is used to locate resource files only.
>
> Thanks,
> Stepan.
>
> >
> >
> >
> >
> > On 6/30/06, Stepan Mishura wrote:
> > >
> > > On 6/30/06, Jimmy, Jing Lv wrote:
> > > >
> > > > Stepan Mishura wrote:
> > > > > Hi Jimmy,
> > > > >
> > > > <SNIP>
> > > > > 3. The test needs ser-files, so it may be necessary to add a
> method
> > to
> > > > >> create this file easily just like the old framework. I find a
> > > protected
> > > > >> method produceGoldenFiles(), is that used for it (why
> protected?)?
> > > This
> > > > >> may be necessary to guildance.
> > > > >> What's more, the ser-file must be end with ".ser", but in new
> > > > framework,
> > > > >> I still find it uses ".dat" . And the path is
> > "test/common/unit/..."
> > > > but
> > > > >> in Harmony's Test Guildance
> > > > tells:"/src/test/resources/serialization..."
> > > > >
> > > > >
> > > > > Yes, I agree that utility method for producing golden files will
> be
> > > > useful.
> > > > > I didn't think how to implement it yet - so suggestion and patches
> > are
> > > > > welcome.
> > > > >
> > > >
> > > > I see now, thank you very much Stepan! :)
> > > > To produce golden files, I believe a little change to
> > > > produceGoldenFiles() may meet this requirement. I'd like to help.:)
> > >
> > >
> > > Great!
> > >
> > > But first of all it may change its search path, as when I create a new
> > > > test and try verifyGolden(), I find a FileNotFoundException. It
> seems
> > > > trying to search "test/common/unit/.../SomeTest.golden.dat", is that
> > > > because of serialization-test for security? Waiting for your
> > refactoring
> > > > :)
> > > >
> > > >
> > > >
> > > > Currently the framework search resource files in the next order:
> > > it tries to load a resource file from the classpath (resource file
> name
> > > should follow new conventions); if it failed then it loads it in 'old'
> > way
> > > (
> > > i.e. using RESOURCE_DIR system property). The 'old' way will be
> removed
> > > after completing 'security' tests migration.
> > >
> > > If you see FileNotFoundException then it means that the framework can
> > find
> > > resource file on the classpath. Please check that:
> > > 1) a resource file follows new naming conventions
> > > 2) a resource file is on the classpath
> > >
> > > BTW, I've refactored one security test[1]. You may wish to use it as
> > > example.
> > >
> > > Thanks,
> > > Stepan Mishura
> > >
> > > P.S.
> > > I'll have random access to e-mail starting next week. Please expect
> some
> > > delay in response.
> > >
> > > [1]
> > >
> > >
> >
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mod
> ules/security/src/test/api/java/org/apache/harmony/security/tests/java/sec
> urity/serialization/KeyPairTest.java?revision=418191&view=markup
> > >
> > > ------------------------------------------------------
> > > 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
> > >
> > >
> >
> >
> > --
> > Andrew Zhang
> > China Software Development Lab, IBM
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> 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
---------------------------------------------------------------------
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
Re: [classlib] trying new framework for testing serialization
Posted by Stepan Mishura <st...@gmail.com>.
Hi Andrew,
On 7/3/06, Andrew Zhang wrote:
>
> Hi Stepan,
>
> I tried serialization test framework, and found it's really easy to use.
> :)
>
> Here I have a small question: why TestCase is designed as first parameter?
Because it is required for all methods for testing compatibility so I made
it as first parameter.
> If I understand correctly, it's used to parse exception name.
No, it is not. It is used to locate resource files only. For example,
TestCase:
org.apache.harmony.luni.tests.java.lang.SomeClassTest
Resource:
org/apache/harmony/luni/tests/java/lang/SomeClassTest.golden.ser
So is it the
> same if we simply pass the String or Class of the object to
> SerializationTest?
Do you mean Class of TestCase or an object to be tested?
Maybe it's a tradeoff for highly automated, still I think pass String or
> Class is not a big deal for user.
>
> Did I miss something? Or TestCase is used for other reasons?
It is used to locate resource files only.
Thanks,
Stepan.
>
>
>
>
> On 6/30/06, Stepan Mishura wrote:
> >
> > On 6/30/06, Jimmy, Jing Lv wrote:
> > >
> > > Stepan Mishura wrote:
> > > > Hi Jimmy,
> > > >
> > > <SNIP>
> > > > 3. The test needs ser-files, so it may be necessary to add a method
> to
> > > >> create this file easily just like the old framework. I find a
> > protected
> > > >> method produceGoldenFiles(), is that used for it (why protected?)?
> > This
> > > >> may be necessary to guildance.
> > > >> What's more, the ser-file must be end with ".ser", but in new
> > > framework,
> > > >> I still find it uses ".dat" . And the path is
> "test/common/unit/..."
> > > but
> > > >> in Harmony's Test Guildance
> > > tells:"/src/test/resources/serialization..."
> > > >
> > > >
> > > > Yes, I agree that utility method for producing golden files will be
> > > useful.
> > > > I didn't think how to implement it yet - so suggestion and patches
> are
> > > > welcome.
> > > >
> > >
> > > I see now, thank you very much Stepan! :)
> > > To produce golden files, I believe a little change to
> > > produceGoldenFiles() may meet this requirement. I'd like to help.:)
> >
> >
> > Great!
> >
> > But first of all it may change its search path, as when I create a new
> > > test and try verifyGolden(), I find a FileNotFoundException. It seems
> > > trying to search "test/common/unit/.../SomeTest.golden.dat", is that
> > > because of serialization-test for security? Waiting for your
> refactoring
> > > :)
> > >
> > >
> > >
> > > Currently the framework search resource files in the next order:
> > it tries to load a resource file from the classpath (resource file name
> > should follow new conventions); if it failed then it loads it in 'old'
> way
> > (
> > i.e. using RESOURCE_DIR system property). The 'old' way will be removed
> > after completing 'security' tests migration.
> >
> > If you see FileNotFoundException then it means that the framework can
> find
> > resource file on the classpath. Please check that:
> > 1) a resource file follows new naming conventions
> > 2) a resource file is on the classpath
> >
> > BTW, I've refactored one security test[1]. You may wish to use it as
> > example.
> >
> > Thanks,
> > Stepan Mishura
> >
> > P.S.
> > I'll have random access to e-mail starting next week. Please expect some
> > delay in response.
> >
> > [1]
> >
> >
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/serialization/KeyPairTest.java?revision=418191&view=markup
> >
> > ------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] trying new framework for testing serialization
Posted by Andrew Zhang <zh...@gmail.com>.
Hi Stepan,
I tried serialization test framework, and found it's really easy to use. :)
Here I have a small question: why TestCase is designed as first parameter?
If I understand correctly, it's used to parse exception name. So is it the
same if we simply pass the String or Class of the object to
SerializationTest?
Maybe it's a tradeoff for highly automated, still I think pass String or
Class is not a big deal for user.
Did I miss something? Or TestCase is used for other reasons?
Thanks!
On 6/30/06, Stepan Mishura <st...@gmail.com> wrote:
>
> On 6/30/06, Jimmy, Jing Lv wrote:
> >
> > Stepan Mishura wrote:
> > > Hi Jimmy,
> > >
> > <SNIP>
> > > 3. The test needs ser-files, so it may be necessary to add a method to
> > >> create this file easily just like the old framework. I find a
> protected
> > >> method produceGoldenFiles(), is that used for it (why protected?)?
> This
> > >> may be necessary to guildance.
> > >> What's more, the ser-file must be end with ".ser", but in new
> > framework,
> > >> I still find it uses ".dat" . And the path is "test/common/unit/..."
> > but
> > >> in Harmony's Test Guildance
> > tells:"/src/test/resources/serialization..."
> > >
> > >
> > > Yes, I agree that utility method for producing golden files will be
> > useful.
> > > I didn't think how to implement it yet - so suggestion and patches are
> > > welcome.
> > >
> >
> > I see now, thank you very much Stepan! :)
> > To produce golden files, I believe a little change to
> > produceGoldenFiles() may meet this requirement. I'd like to help.:)
>
>
> Great!
>
> But first of all it may change its search path, as when I create a new
> > test and try verifyGolden(), I find a FileNotFoundException. It seems
> > trying to search "test/common/unit/.../SomeTest.golden.dat", is that
> > because of serialization-test for security? Waiting for your refactoring
> > :)
> >
> >
> >
> > Currently the framework search resource files in the next order:
> it tries to load a resource file from the classpath (resource file name
> should follow new conventions); if it failed then it loads it in 'old' way
> (
> i.e. using RESOURCE_DIR system property). The 'old' way will be removed
> after completing 'security' tests migration.
>
> If you see FileNotFoundException then it means that the framework can find
> resource file on the classpath. Please check that:
> 1) a resource file follows new naming conventions
> 2) a resource file is on the classpath
>
> BTW, I've refactored one security test[1]. You may wish to use it as
> example.
>
> Thanks,
> Stepan Mishura
>
> P.S.
> I'll have random access to e-mail starting next week. Please expect some
> delay in response.
>
> [1]
>
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/serialization/KeyPairTest.java?revision=418191&view=markup
>
> ------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] trying new framework for testing serialization
Posted by Stepan Mishura <st...@gmail.com>.
On 6/30/06, Jimmy, Jing Lv wrote:
>
> Stepan Mishura wrote:
> > Hi Jimmy,
> >
> <SNIP>
> > 3. The test needs ser-files, so it may be necessary to add a method to
> >> create this file easily just like the old framework. I find a protected
> >> method produceGoldenFiles(), is that used for it (why protected?)? This
> >> may be necessary to guildance.
> >> What's more, the ser-file must be end with ".ser", but in new
> framework,
> >> I still find it uses ".dat" . And the path is "test/common/unit/..."
> but
> >> in Harmony's Test Guildance
> tells:"/src/test/resources/serialization..."
> >
> >
> > Yes, I agree that utility method for producing golden files will be
> useful.
> > I didn't think how to implement it yet - so suggestion and patches are
> > welcome.
> >
>
> I see now, thank you very much Stepan! :)
> To produce golden files, I believe a little change to
> produceGoldenFiles() may meet this requirement. I'd like to help.:)
Great!
But first of all it may change its search path, as when I create a new
> test and try verifyGolden(), I find a FileNotFoundException. It seems
> trying to search "test/common/unit/.../SomeTest.golden.dat", is that
> because of serialization-test for security? Waiting for your refactoring
> :)
>
>
>
> Currently the framework search resource files in the next order:
it tries to load a resource file from the classpath (resource file name
should follow new conventions); if it failed then it loads it in 'old' way (
i.e. using RESOURCE_DIR system property). The 'old' way will be removed
after completing 'security' tests migration.
If you see FileNotFoundException then it means that the framework can find
resource file on the classpath. Please check that:
1) a resource file follows new naming conventions
2) a resource file is on the classpath
BTW, I've refactored one security test[1]. You may wish to use it as
example.
Thanks,
Stepan Mishura
P.S.
I'll have random access to e-mail starting next week. Please expect some
delay in response.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/serialization/KeyPairTest.java?revision=418191&view=markup
------------------------------------------------------
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
Re: [classlib] trying new framework for testing serialization
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Stepan Mishura wrote:
> Hi Jimmy,
>
> On 6/30/06, Jimmy, Jing Lv wrote:
>>
>> Hi Stepan:
>>
>> Seems the new framework for serialization has added to Harmony, I'm
>> trying it and find it interesting. However I have a few questions:
>>
>> 1. It is strange that SerializationTest is an abstract class extends
>> junit.framework.testcase, in this case I can either (a) extends
>> SerializationTest directly, implements getData() and run, it shall run
>> "testSelf" and "testGolden", but how to control more complex situation
>> in this way? or (b) write a test extends testcase, and use static
>> methods "verifySelf" and "verifyGolden" in SerializationTest as
>> Guidelines says, however I wonder why it extends testcase?
>
>
> You should use approach described in [1]. The second way (i.e. extending
> SerializationTest) is used by 'security' serialization tests only. As we
> agreed we won't use it and all 'security' serialization tests should be
> refactored to avoid extending SerializationTest. However it hard to do at
> once. So I put stubs to "testSelf" and "testGolden" methods to let
> 'security' tests smoothly migrate to the new testing approach.
>
> Please follow conventions in [1] for creating new serialization tests.
>
> 2. It is strange verifyGolden(test, object) has two parameter, but in
>> the example in the Guidelines says:"
>> public void testSerializationCompatibility()
>> throws Exception {
>> SerializationTest.verifyGolden(new SomeSerializableClass());
>> }" something lost?
>> And I guess the first parameter is used only to parse the name of
>> resource file. If so, may it change the parameter to a String, or
>> something else?
>
>
> Yes, it is a mistake. Somebody already caught it and I fixed it in r417133
> but the page on the web-site didn't updated yet. So I should say:
>
> public void testSerializationCompatibility()
> throws Exception {
>
> SerializationTest.verifyGolden(this, new SomeSerializableClass());
> }
>
> The first param is TestCase instance that is used to locate golden file.
>
> 3. The test needs ser-files, so it may be necessary to add a method to
>> create this file easily just like the old framework. I find a protected
>> method produceGoldenFiles(), is that used for it (why protected?)? This
>> may be necessary to guildance.
>> What's more, the ser-file must be end with ".ser", but in new framework,
>> I still find it uses ".dat" . And the path is "test/common/unit/..." but
>> in Harmony's Test Guildance tells:"/src/test/resources/serialization..."
>
>
> Yes, I agree that utility method for producing golden files will be useful.
> I didn't think how to implement it yet - so suggestion and patches are
> welcome.
>
I see now, thank you very much Stepan! :)
To produce golden files, I believe a little change to
produceGoldenFiles() may meet this requirement. I'd like to help.:)
But first of all it may change its search path, as when I create a new
test and try verifyGolden(), I find a FileNotFoundException. It seems
trying to search "test/common/unit/.../SomeTest.golden.dat", is that
because of serialization-test for security? Waiting for your refactoring :)
> Thanks,
> Stepan.
>
> [1]
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>
>
> Your comments? Thanks!
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>>
>
>
--
Best Regards!
Jimmy, Jing Lv
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
Re: [classlib] trying new framework for testing serialization (was:Merging frameworks for testing serialization - first step)
Posted by Stepan Mishura <st...@gmail.com>.
Hi Jimmy,
On 6/30/06, Jimmy, Jing Lv wrote:
>
> Hi Stepan:
>
> Seems the new framework for serialization has added to Harmony, I'm
> trying it and find it interesting. However I have a few questions:
>
> 1. It is strange that SerializationTest is an abstract class extends
> junit.framework.testcase, in this case I can either (a) extends
> SerializationTest directly, implements getData() and run, it shall run
> "testSelf" and "testGolden", but how to control more complex situation
> in this way? or (b) write a test extends testcase, and use static
> methods "verifySelf" and "verifyGolden" in SerializationTest as
> Guidelines says, however I wonder why it extends testcase?
You should use approach described in [1]. The second way (i.e. extending
SerializationTest) is used by 'security' serialization tests only. As we
agreed we won't use it and all 'security' serialization tests should be
refactored to avoid extending SerializationTest. However it hard to do at
once. So I put stubs to "testSelf" and "testGolden" methods to let
'security' tests smoothly migrate to the new testing approach.
Please follow conventions in [1] for creating new serialization tests.
2. It is strange verifyGolden(test, object) has two parameter, but in
> the example in the Guidelines says:"
> public void testSerializationCompatibility()
> throws Exception {
> SerializationTest.verifyGolden(new SomeSerializableClass());
> }" something lost?
> And I guess the first parameter is used only to parse the name of
> resource file. If so, may it change the parameter to a String, or
> something else?
Yes, it is a mistake. Somebody already caught it and I fixed it in r417133
but the page on the web-site didn't updated yet. So I should say:
public void testSerializationCompatibility()
throws Exception {
SerializationTest.verifyGolden(this, new SomeSerializableClass());
}
The first param is TestCase instance that is used to locate golden file.
3. The test needs ser-files, so it may be necessary to add a method to
> create this file easily just like the old framework. I find a protected
> method produceGoldenFiles(), is that used for it (why protected?)? This
> may be necessary to guildance.
> What's more, the ser-file must be end with ".ser", but in new framework,
> I still find it uses ".dat" . And the path is "test/common/unit/..." but
> in Harmony's Test Guildance tells:"/src/test/resources/serialization..."
Yes, I agree that utility method for producing golden files will be useful.
I didn't think how to implement it yet - so suggestion and patches are
welcome.
Thanks,
Stepan.
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
Your comments? Thanks!
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] trying new framework for testing serialization
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Jimmy, Jing Lv wrote:
> Hi Stepan:
>
> Seems the new framework for serialization has added to Harmony, I'm
> trying it and find it interesting. However I have a few questions:
>
> 1. It is strange that SerializationTest is an abstract class extends
> junit.framework.testcase, in this case I can either (a) extends
> SerializationTest directly, implements getData() and run, it shall run
> "testSelf" and "testGolden", but how to control more complex situation
> in this way? or (b) write a test extends testcase, and use static
> methods "verifySelf" and "verifyGolden" in SerializationTest as
> Guidelines says, however I wonder why it extends testcase?
>
By reading old threads, I've aware that these two ways are both OK, but
the Guidelines say nothing about it, so may you tell me some detail
about it? Thanks! :)
> 2. It is strange verifyGolden(test, object) has two parameter, but in
> the example in the Guidelines says:"
> public void testSerializationCompatibility()
> throws Exception {
> SerializationTest.verifyGolden(new SomeSerializableClass());
> }" something lost?
> And I guess the first parameter is used only to parse the name of
> resource file. If so, may it change the parameter to a String, or
> something else?
>
> 3. The test needs ser-files, so it may be necessary to add a method to
> create this file easily just like the old framework. I find a protected
> method produceGoldenFiles(), is that used for it (why protected?)? This
> may be necessary to guildance.
> What's more, the ser-file must be end with ".ser", but in new framework,
> I still find it uses ".dat" . And the path is "test/common/unit/..." but
> in Harmony's Test Guildance tells:"/src/test/resources/serialization..."
>
> Your comments? Thanks!
>
--
Best Regards!
Jimmy, Jing Lv
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
[classlib] trying new framework for testing serialization (was:Merging
frameworks for testing serialization - first step)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Hi Stepan:
Seems the new framework for serialization has added to Harmony, I'm
trying it and find it interesting. However I have a few questions:
1. It is strange that SerializationTest is an abstract class extends
junit.framework.testcase, in this case I can either (a) extends
SerializationTest directly, implements getData() and run, it shall run
"testSelf" and "testGolden", but how to control more complex situation
in this way? or (b) write a test extends testcase, and use static
methods "verifySelf" and "verifyGolden" in SerializationTest as
Guidelines says, however I wonder why it extends testcase?
2. It is strange verifyGolden(test, object) has two parameter, but in
the example in the Guidelines says:"
public void testSerializationCompatibility()
throws Exception {
SerializationTest.verifyGolden(new SomeSerializableClass());
}" something lost?
And I guess the first parameter is used only to parse the name of
resource file. If so, may it change the parameter to a String, or
something else?
3. The test needs ser-files, so it may be necessary to add a method to
create this file easily just like the old framework. I find a protected
method produceGoldenFiles(), is that used for it (why protected?)? This
may be necessary to guildance.
What's more, the ser-file must be end with ".ser", but in new framework,
I still find it uses ".dat" . And the path is "test/common/unit/..." but
in Harmony's Test Guildance tells:"/src/test/resources/serialization..."
Your comments? Thanks!
--
Best Regards!
Jimmy, Jing Lv
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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
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: 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
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] Merging frameworks for testing serialization - first
step
Posted by Paulex Yang <pa...@gmail.com>.
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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
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
Re: [classlib] Merging frameworks for testing serialization - first
step
Posted by Paulex Yang <pa...@gmail.com>.
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: 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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
On 6/27/06, Geir Magnusson Jr wrote:
>
>
> Stepan Mishura wrote:
> > On 6/27/06, Geir Magnusson Jr wrote:
> >>
> >> One minor thing - if you do an ant rebuild and then go into a module to
> >> test something specific, it won't work because the support stuff
> doesn't
> >> get build.
> >>
> >> I don't know the right solution. Maybe the module build.xml triggers
> >> building the support test, or just a note somewhere to remind people?
> >
> >
> > I think adding 'support.jar' to classpath will help.
>
> Not if it's not built. That's the issue. There's no problem if you do
> an ant test from /trunk, but if you are 'clean', and then just dive into
> modules/$foo and ant test from there, you're stuck.
OK, I see what you mean. But this doesn't relate to moving SerializationTest
to support.
For example, if you are do 'ant clean' in the classlib and then 'cd
modules/security; ant test'. You will see:
Buildfile: build.xml
compile.java:
[echo] Compiling SECURITY classes
[javac] Compiling 262 source files to
C:\Apache\Harmony\ClassLib\build\classes
[javac] Fatal Error: Unable to find package java.lang in classpath or
bootclasspath
BUILD FAILED
C:\Apache\Harmony\ClassLib\modules\security\build.xml:62: Compile failed;
see the compiler error output for details.
Thanks,
Stepan.
> Not a big deal, just figured someone might be inconvenienced, and if we
> either had a fix or a note, that would be cool.
>
> geir
>
> >
> > Thanks,
> > Stepan.
> >
> > geir
> >>
> >>
> >> Stepan Mishura wrote:
> >> > On 6/26/06, Tim Ellison wrote:
> >> >>
> >> >> Stepan Mishura wrote:
> >> >> > On 6/26/06, Tim Ellison wrote:
> >> >> >>
> >> >> >> Stepan Mishura wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > I've updated framework for testing serialization page[1] - I
> >> added
> >> >> >> > guidelines
> >> >> >> > for developing serialization tests. Also I've removed confusing
> >> >> >> 'TestCase'
> >> >> >> > parameter in SerializationTest.verifySelf() methods.
> >> >> >> >
> >> >> >> > If there are no objections I'm going in next two days to move
> >> >> >> > SerializationTest.java from 'security' module to support
> folder.
> >> So
> >> >> new
> >> >> >> > location will be:
> >> >> >> >
> >> support/src/test/java/org/apache/harmony/testframework/serialization
> >> >> >> > folder.
> >> >> >> > Class name won't change.
> >> >> >> >
> >> >> >> > Thoughts?
> >> >> >>
> >> >> >> Looks good, just a couple of minor comments:
> >> >> >>
> >> >> >> - You might as well move them (or duplicate them) to an
> >> >> >> org.apache.harmony. package while you are moving things around,
> >> since
> >> >> we
> >> >> >> want to get rid of tests.util as a package name.
> >> >> >
> >> >> > 'Them' means tests, right?
> >> >>
> >> >> Sorry, I actually meant the testing framework itself. The doc says
> >> >>
> >> >> "The testing framework provides support class
> >> >> tests.util.SerializationTest for serialization testing."
> >> >>
> >> >> I figured it would be easier to put them in the right place.
> >> >
> >> >
> >> > Ops..., sorry. I thought about replacing SerializationTester and
> >> > accidentally put its package name. It should say:
> >> > " The testing framework provides support class
> >> > org.apache.harmony.testframework.serialization.SerializationTest for
> >> > serialization testing."
> >> >
> >> > I fixed the doc in r417196. Looks better now? :-)
> >> >
> >> >> - Please will you ensure that the Manifests are updated accordingly
> so
> >> >> >> that the world is not broken.
> >> >> >
> >> >> >
> >> >> > Sure, I will try.
> >> >> >
> >> >> > - Not sure about the word 'golden' to mean 'reference' data, when
> we
> >> >> >> could just use reference, but whatever.
> >> >> >
> >> >> > In the method names or resource file name? Or both?
> >> >>
> >> >> Ideally both, it just seems like jargon -- but I realize that such
> >> >> renaming doesn't really 'advance the cause', so whatever you think.
> >> >
> >> >
> >> > I'm OK with 'reference' and currently 'golden' can be easily replaced
> >> with
> >> > it. Otherwise after we rename everything it will be not so simple.
> >> >
> >> > Thanks,
> >> > Stepan.
> >> >
> >> > Regards,
> >> >> Tim
> >> >>
> >> >> >> >
> >> >> >> > [1]
> >> >> >> >
> >> >> >>
> >> >>
> >>
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
> >>
> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > On 6/20/06, 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)
> >> >> >> >> verifyGolden(TestCase, Object, SerializableAssert)
> >> >> >> >> verifyGolden(TestCase, Object[])
> >> >> >> >> verifyGolden(TestCase, Object[], SerializableAssert)
> >> >> >> >>
> >> >> >> >> 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)
> >> >> >> >>
> >> >> >> >> 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.
> >> >> >> >>
> >> >> >> >> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Merging frameworks for testing serialization - first
step
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stepan Mishura wrote:
> On 6/27/06, Geir Magnusson Jr wrote:
>>
>> One minor thing - if you do an ant rebuild and then go into a module to
>> test something specific, it won't work because the support stuff doesn't
>> get build.
>>
>> I don't know the right solution. Maybe the module build.xml triggers
>> building the support test, or just a note somewhere to remind people?
>
>
> I think adding 'support.jar' to classpath will help.
Not if it's not built. That's the issue. There's no problem if you do
an ant test from /trunk, but if you are 'clean', and then just dive into
modules/$foo and ant test from there, you're stuck.
Not a big deal, just figured someone might be inconvenienced, and if we
either had a fix or a note, that would be cool.
geir
>
> Thanks,
> Stepan.
>
> geir
>>
>>
>> Stepan Mishura wrote:
>> > On 6/26/06, Tim Ellison wrote:
>> >>
>> >> Stepan Mishura wrote:
>> >> > On 6/26/06, Tim Ellison wrote:
>> >> >>
>> >> >> Stepan Mishura wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I've updated framework for testing serialization page[1] - I
>> added
>> >> >> > guidelines
>> >> >> > for developing serialization tests. Also I've removed confusing
>> >> >> 'TestCase'
>> >> >> > parameter in SerializationTest.verifySelf() methods.
>> >> >> >
>> >> >> > If there are no objections I'm going in next two days to move
>> >> >> > SerializationTest.java from 'security' module to support folder.
>> So
>> >> new
>> >> >> > location will be:
>> >> >> >
>> support/src/test/java/org/apache/harmony/testframework/serialization
>> >> >> > folder.
>> >> >> > Class name won't change.
>> >> >> >
>> >> >> > Thoughts?
>> >> >>
>> >> >> Looks good, just a couple of minor comments:
>> >> >>
>> >> >> - You might as well move them (or duplicate them) to an
>> >> >> org.apache.harmony. package while you are moving things around,
>> since
>> >> we
>> >> >> want to get rid of tests.util as a package name.
>> >> >
>> >> > 'Them' means tests, right?
>> >>
>> >> Sorry, I actually meant the testing framework itself. The doc says
>> >>
>> >> "The testing framework provides support class
>> >> tests.util.SerializationTest for serialization testing."
>> >>
>> >> I figured it would be easier to put them in the right place.
>> >
>> >
>> > Ops..., sorry. I thought about replacing SerializationTester and
>> > accidentally put its package name. It should say:
>> > " The testing framework provides support class
>> > org.apache.harmony.testframework.serialization.SerializationTest for
>> > serialization testing."
>> >
>> > I fixed the doc in r417196. Looks better now? :-)
>> >
>> >> - Please will you ensure that the Manifests are updated accordingly so
>> >> >> that the world is not broken.
>> >> >
>> >> >
>> >> > Sure, I will try.
>> >> >
>> >> > - Not sure about the word 'golden' to mean 'reference' data, when we
>> >> >> could just use reference, but whatever.
>> >> >
>> >> > In the method names or resource file name? Or both?
>> >>
>> >> Ideally both, it just seems like jargon -- but I realize that such
>> >> renaming doesn't really 'advance the cause', so whatever you think.
>> >
>> >
>> > I'm OK with 'reference' and currently 'golden' can be easily replaced
>> with
>> > it. Otherwise after we rename everything it will be not so simple.
>> >
>> > Thanks,
>> > Stepan.
>> >
>> > Regards,
>> >> Tim
>> >>
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >>
>> >>
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >>
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > On 6/20/06, 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)
>> >> >> >> verifyGolden(TestCase, Object, SerializableAssert)
>> >> >> >> verifyGolden(TestCase, Object[])
>> >> >> >> verifyGolden(TestCase, Object[], SerializableAssert)
>> >> >> >>
>> >> >> >> 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)
>> >> >> >>
>> >> >> >> 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.
>> >> >> >>
>> >> >> >> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
On 6/27/06, Geir Magnusson Jr wrote:
>
> One minor thing - if you do an ant rebuild and then go into a module to
> test something specific, it won't work because the support stuff doesn't
> get build.
>
> I don't know the right solution. Maybe the module build.xml triggers
> building the support test, or just a note somewhere to remind people?
I think adding 'support.jar' to classpath will help.
Thanks,
Stepan.
geir
>
>
> Stepan Mishura wrote:
> > On 6/26/06, Tim Ellison wrote:
> >>
> >> Stepan Mishura wrote:
> >> > On 6/26/06, Tim Ellison wrote:
> >> >>
> >> >> Stepan Mishura wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I've updated framework for testing serialization page[1] - I added
> >> >> > guidelines
> >> >> > for developing serialization tests. Also I've removed confusing
> >> >> 'TestCase'
> >> >> > parameter in SerializationTest.verifySelf() methods.
> >> >> >
> >> >> > If there are no objections I'm going in next two days to move
> >> >> > SerializationTest.java from 'security' module to support folder.
> So
> >> new
> >> >> > location will be:
> >> >> >
> support/src/test/java/org/apache/harmony/testframework/serialization
> >> >> > folder.
> >> >> > Class name won't change.
> >> >> >
> >> >> > Thoughts?
> >> >>
> >> >> Looks good, just a couple of minor comments:
> >> >>
> >> >> - You might as well move them (or duplicate them) to an
> >> >> org.apache.harmony. package while you are moving things around,
> since
> >> we
> >> >> want to get rid of tests.util as a package name.
> >> >
> >> > 'Them' means tests, right?
> >>
> >> Sorry, I actually meant the testing framework itself. The doc says
> >>
> >> "The testing framework provides support class
> >> tests.util.SerializationTest for serialization testing."
> >>
> >> I figured it would be easier to put them in the right place.
> >
> >
> > Ops..., sorry. I thought about replacing SerializationTester and
> > accidentally put its package name. It should say:
> > " The testing framework provides support class
> > org.apache.harmony.testframework.serialization.SerializationTest for
> > serialization testing."
> >
> > I fixed the doc in r417196. Looks better now? :-)
> >
> >> - Please will you ensure that the Manifests are updated accordingly so
> >> >> that the world is not broken.
> >> >
> >> >
> >> > Sure, I will try.
> >> >
> >> > - Not sure about the word 'golden' to mean 'reference' data, when we
> >> >> could just use reference, but whatever.
> >> >
> >> > In the method names or resource file name? Or both?
> >>
> >> Ideally both, it just seems like jargon -- but I realize that such
> >> renaming doesn't really 'advance the cause', so whatever you think.
> >
> >
> > I'm OK with 'reference' and currently 'golden' can be easily replaced
> with
> > it. Otherwise after we rename everything it will be not so simple.
> >
> > Thanks,
> > Stepan.
> >
> > Regards,
> >> Tim
> >>
> >> >> >
> >> >> > [1]
> >> >> >
> >> >>
> >>
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
> >>
> >> >>
> >> >> >
> >> >> >
> >> >> > On 6/20/06, 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)
> >> >> >> verifyGolden(TestCase, Object, SerializableAssert)
> >> >> >> verifyGolden(TestCase, Object[])
> >> >> >> verifyGolden(TestCase, Object[], SerializableAssert)
> >> >> >>
> >> >> >> 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)
> >> >> >>
> >> >> >> 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.
> >> >> >>
> >> >> >> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Merging frameworks for testing serialization - first
step
Posted by Geir Magnusson Jr <ge...@pobox.com>.
One minor thing - if you do an ant rebuild and then go into a module to
test something specific, it won't work because the support stuff doesn't
get build.
I don't know the right solution. Maybe the module build.xml triggers
building the support test, or just a note somewhere to remind people?
geir
Stepan Mishura wrote:
> On 6/26/06, Tim Ellison wrote:
>>
>> Stepan Mishura wrote:
>> > On 6/26/06, Tim Ellison wrote:
>> >>
>> >> Stepan Mishura wrote:
>> >> > Hi,
>> >> >
>> >> > I've updated framework for testing serialization page[1] - I added
>> >> > guidelines
>> >> > for developing serialization tests. Also I've removed confusing
>> >> 'TestCase'
>> >> > parameter in SerializationTest.verifySelf() methods.
>> >> >
>> >> > If there are no objections I'm going in next two days to move
>> >> > SerializationTest.java from 'security' module to support folder. So
>> new
>> >> > location will be:
>> >> > support/src/test/java/org/apache/harmony/testframework/serialization
>> >> > folder.
>> >> > Class name won't change.
>> >> >
>> >> > Thoughts?
>> >>
>> >> Looks good, just a couple of minor comments:
>> >>
>> >> - You might as well move them (or duplicate them) to an
>> >> org.apache.harmony. package while you are moving things around, since
>> we
>> >> want to get rid of tests.util as a package name.
>> >
>> > 'Them' means tests, right?
>>
>> Sorry, I actually meant the testing framework itself. The doc says
>>
>> "The testing framework provides support class
>> tests.util.SerializationTest for serialization testing."
>>
>> I figured it would be easier to put them in the right place.
>
>
> Ops..., sorry. I thought about replacing SerializationTester and
> accidentally put its package name. It should say:
> " The testing framework provides support class
> org.apache.harmony.testframework.serialization.SerializationTest for
> serialization testing."
>
> I fixed the doc in r417196. Looks better now? :-)
>
>> - Please will you ensure that the Manifests are updated accordingly so
>> >> that the world is not broken.
>> >
>> >
>> > Sure, I will try.
>> >
>> > - Not sure about the word 'golden' to mean 'reference' data, when we
>> >> could just use reference, but whatever.
>> >
>> > In the method names or resource file name? Or both?
>>
>> Ideally both, it just seems like jargon -- but I realize that such
>> renaming doesn't really 'advance the cause', so whatever you think.
>
>
> I'm OK with 'reference' and currently 'golden' can be easily replaced with
> it. Otherwise after we rename everything it will be not so simple.
>
> Thanks,
> Stepan.
>
> Regards,
>> Tim
>>
>> >> >
>> >> > [1]
>> >> >
>> >>
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >>
>> >> >
>> >> >
>> >> > On 6/20/06, 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)
>> >> >> verifyGolden(TestCase, Object, SerializableAssert)
>> >> >> verifyGolden(TestCase, Object[])
>> >> >> verifyGolden(TestCase, Object[], SerializableAssert)
>> >> >>
>> >> >> 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)
>> >> >>
>> >> >> 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.
>> >> >>
>> >> >> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
On 6/26/06, Tim Ellison wrote:
>
> Stepan Mishura wrote:
> > On 6/26/06, Tim Ellison wrote:
> >>
> >> Stepan Mishura wrote:
> >> > Hi,
> >> >
> >> > I've updated framework for testing serialization page[1] - I added
> >> > guidelines
> >> > for developing serialization tests. Also I've removed confusing
> >> 'TestCase'
> >> > parameter in SerializationTest.verifySelf() methods.
> >> >
> >> > If there are no objections I'm going in next two days to move
> >> > SerializationTest.java from 'security' module to support folder. So
> new
> >> > location will be:
> >> > support/src/test/java/org/apache/harmony/testframework/serialization
> >> > folder.
> >> > Class name won't change.
> >> >
> >> > Thoughts?
> >>
> >> Looks good, just a couple of minor comments:
> >>
> >> - You might as well move them (or duplicate them) to an
> >> org.apache.harmony. package while you are moving things around, since
> we
> >> want to get rid of tests.util as a package name.
> >
> > 'Them' means tests, right?
>
> Sorry, I actually meant the testing framework itself. The doc says
>
> "The testing framework provides support class
> tests.util.SerializationTest for serialization testing."
>
> I figured it would be easier to put them in the right place.
Ops..., sorry. I thought about replacing SerializationTester and
accidentally put its package name. It should say:
" The testing framework provides support class
org.apache.harmony.testframework.serialization.SerializationTest for
serialization testing."
I fixed the doc in r417196. Looks better now? :-)
> - Please will you ensure that the Manifests are updated accordingly so
> >> that the world is not broken.
> >
> >
> > Sure, I will try.
> >
> > - Not sure about the word 'golden' to mean 'reference' data, when we
> >> could just use reference, but whatever.
> >
> > In the method names or resource file name? Or both?
>
> Ideally both, it just seems like jargon -- but I realize that such
> renaming doesn't really 'advance the cause', so whatever you think.
I'm OK with 'reference' and currently 'golden' can be easily replaced with
it. Otherwise after we rename everything it will be not so simple.
Thanks,
Stepan.
Regards,
> Tim
>
> >> >
> >> > [1]
> >> >
> >>
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
> >>
> >> >
> >> >
> >> > On 6/20/06, 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)
> >> >> verifyGolden(TestCase, Object, SerializableAssert)
> >> >> verifyGolden(TestCase, Object[])
> >> >> verifyGolden(TestCase, Object[], SerializableAssert)
> >> >>
> >> >> 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)
> >> >>
> >> >> 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.
> >> >>
> >> >> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Merging frameworks for testing serialization - first
step
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> On 6/26/06, Tim Ellison wrote:
>>
>> Stepan Mishura wrote:
>> > Hi,
>> >
>> > I've updated framework for testing serialization page[1] - I added
>> > guidelines
>> > for developing serialization tests. Also I've removed confusing
>> 'TestCase'
>> > parameter in SerializationTest.verifySelf() methods.
>> >
>> > If there are no objections I'm going in next two days to move
>> > SerializationTest.java from 'security' module to support folder. So new
>> > location will be:
>> > support/src/test/java/org/apache/harmony/testframework/serialization
>> > folder.
>> > Class name won't change.
>> >
>> > Thoughts?
>>
>> Looks good, just a couple of minor comments:
>>
>> - You might as well move them (or duplicate them) to an
>> org.apache.harmony. package while you are moving things around, since we
>> want to get rid of tests.util as a package name.
>
> 'Them' means tests, right?
Sorry, I actually meant the testing framework itself. The doc says
"The testing framework provides support class
tests.util.SerializationTest for serialization testing."
I figured it would be easier to put them in the right place.
> - Please will you ensure that the Manifests are updated accordingly so
>> that the world is not broken.
>
>
> Sure, I will try.
>
> - Not sure about the word 'golden' to mean 'reference' data, when we
>> could just use reference, but whatever.
>
> In the method names or resource file name? Or both?
Ideally both, it just seems like jargon -- but I realize that such
renaming doesn't really 'advance the cause', so whatever you think.
Regards,
Tim
>> >
>> > [1]
>> >
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >
>> >
>> > On 6/20/06, 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)
>> >> verifyGolden(TestCase, Object, SerializableAssert)
>> >> verifyGolden(TestCase, Object[])
>> >> verifyGolden(TestCase, Object[], SerializableAssert)
>> >>
>> >> 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)
>> >>
>> >> 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.
>> >>
>> >> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
On 6/26/06, Tim Ellison wrote:
>
> Stepan Mishura wrote:
> > Hi,
> >
> > I've updated framework for testing serialization page[1] - I added
> > guidelines
> > for developing serialization tests. Also I've removed confusing
> 'TestCase'
> > parameter in SerializationTest.verifySelf() methods.
> >
> > If there are no objections I'm going in next two days to move
> > SerializationTest.java from 'security' module to support folder. So new
> > location will be:
> > support/src/test/java/org/apache/harmony/testframework/serialization
> > folder.
> > Class name won't change.
> >
> > Thoughts?
>
> Looks good, just a couple of minor comments:
>
> - You might as well move them (or duplicate them) to an
> org.apache.harmony. package while you are moving things around, since we
> want to get rid of tests.util as a package name.
'Them' means tests, right?
- Please will you ensure that the Manifests are updated accordingly so
> that the world is not broken.
Sure, I will try.
- Not sure about the word 'golden' to mean 'reference' data, when we
> could just use reference, but whatever.
In the method names or resource file name? Or both?
Thanks,
Stepan.
Regards,
> Tim
>
>
> > Thanks,
> > Stepan.
> >
> > [1]
> >
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
> >
> >
> > On 6/20/06, 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)
> >> verifyGolden(TestCase, Object, SerializableAssert)
> >> verifyGolden(TestCase, Object[])
> >> verifyGolden(TestCase, Object[], SerializableAssert)
> >>
> >> 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)
> >>
> >> 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.
> >>
> >> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Merging frameworks for testing serialization - first
step
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> Hi,
>
> I've updated framework for testing serialization page[1] - I added
> guidelines
> for developing serialization tests. Also I've removed confusing 'TestCase'
> parameter in SerializationTest.verifySelf() methods.
>
> If there are no objections I'm going in next two days to move
> SerializationTest.java from 'security' module to support folder. So new
> location will be:
> support/src/test/java/org/apache/harmony/testframework/serialization
> folder.
> Class name won't change.
>
> Thoughts?
Looks good, just a couple of minor comments:
- You might as well move them (or duplicate them) to an
org.apache.harmony. package while you are moving things around, since we
want to get rid of tests.util as a package name.
- Please will you ensure that the Manifests are updated accordingly so
that the world is not broken.
- Not sure about the word 'golden' to mean 'reference' data, when we
could just use reference, but whatever.
Regards,
Tim
> Thanks,
> Stepan.
>
> [1]
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>
>
> On 6/20/06, 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)
>> verifyGolden(TestCase, Object, SerializableAssert)
>> verifyGolden(TestCase, Object[])
>> verifyGolden(TestCase, Object[], SerializableAssert)
>>
>> 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)
>>
>> 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.
>>
>> 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: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
On 6/24/06, Richard Liang wrote:
>
>
>
> Stepan Mishura wrote:
> > Hi,
> >
> > I've updated framework for testing serialization page[1] - I added
> > guidelines
> > for developing serialization tests. Also I've removed confusing
> > 'TestCase'
> > parameter in SerializationTest.verifySelf() methods.
> >
> > If there are no objections I'm going in next two days to move
> > SerializationTest.java from 'security' module to support folder. So new
> > location will be:
> > support/src/test/java/org/apache/harmony/testframework/serialization
> > folder.
> > Class name won't change.
> >
> > Thoughts?
> Sounds good, Stepan. So next step we will upgrade all the serialization
> test, right? ;-)
Yes, we can start replacing SerializationTester with SerializationTest.
Thanks,
Stepan.
Best regards,
> Richard.
> >
> > Thanks,
> > Stepan.
> >
> > [1]
> >
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
> >
> >
> > On 6/20/06, 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)
> >> verifyGolden(TestCase, Object, SerializableAssert)
> >> verifyGolden(TestCase, Object[])
> >> verifyGolden(TestCase, Object[], SerializableAssert)
> >>
> >> 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)
> >>
> >> 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.
> >>
> >> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Merging frameworks for testing serialization - first
step
Posted by Richard Liang <ri...@gmail.com>.
Stepan Mishura wrote:
> Hi,
>
> I've updated framework for testing serialization page[1] - I added
> guidelines
> for developing serialization tests. Also I've removed confusing
> 'TestCase'
> parameter in SerializationTest.verifySelf() methods.
>
> If there are no objections I'm going in next two days to move
> SerializationTest.java from 'security' module to support folder. So new
> location will be:
> support/src/test/java/org/apache/harmony/testframework/serialization
> folder.
> Class name won't change.
>
> Thoughts?
Sounds good, Stepan. So next step we will upgrade all the serialization
test, right? ;-)
Best regards,
Richard.
>
> Thanks,
> Stepan.
>
> [1]
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>
>
> On 6/20/06, 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)
>> verifyGolden(TestCase, Object, SerializableAssert)
>> verifyGolden(TestCase, Object[])
>> verifyGolden(TestCase, Object[], SerializableAssert)
>>
>> 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)
>>
>> 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.
>>
>> 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: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
>
--
Richard Liang
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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/26/06, Stepan Mishura <st...@gmail.com> wrote:
>
> On 6/24/06, Andrew Zhang wrote:
> >
> > Welldone stepan!
> >
> > I have a small question about the sample from serialization page[1]:
> >
> >
> > public void testSerializationCompatibility()
> > throws Exception {
> >
> > SerializationTest.verifyGolden(new SomeSerializableClass());
> > }
> >
> > Any argument for ****.golden.ser? Typing error?
>
>
> Good catch! I missed 'TestCase' param in the example - fixed in r417133.
:) Stepan, I'm writing serialization tests for NIO module currently, and
still using SerializationTester.
I'll update these serialization tests once the new test framework is ready!
Thanks!
Thanks,
> Stepan.
>
> Thanks!
> > On 6/23/06, Stepan Mishura <st...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I've updated framework for testing serialization page[1] - I added
> > > guidelines
> > > for developing serialization tests. Also I've removed confusing
> > 'TestCase'
> > > parameter in SerializationTest.verifySelf() methods.
> > >
> > > If there are no objections I'm going in next two days to move
> > > SerializationTest.java from 'security' module to support folder. So
> new
> > > location will be:
> > > support/src/test/java/org/apache/harmony/testframework/serialization
> > > folder.
> > > Class name won't change.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Stepan.
> > >
> > > [1]
> > >
> > >
> >
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
> > >
> > > On 6/20/06, 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)
> > > > verifyGolden(TestCase, Object, SerializableAssert)
> > > > verifyGolden(TestCase, Object[])
> > > > verifyGolden(TestCase, Object[], SerializableAssert)
> > > >
> > > > 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)
> > > >
> > > > 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.
> > > >
> > > > 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: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Stepan Mishura
> > > Intel Middleware Products Division
> > >
> > > ------------------------------------------------------
> > > 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
> > >
> > >
> >
> >
> > --
> > Andrew Zhang
> > China Software Development Lab, IBM
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
On 6/24/06, Andrew Zhang wrote:
>
> Welldone stepan!
>
> I have a small question about the sample from serialization page[1]:
>
>
> public void testSerializationCompatibility()
> throws Exception {
>
> SerializationTest.verifyGolden(new SomeSerializableClass());
> }
>
> Any argument for ****.golden.ser? Typing error?
Good catch! I missed 'TestCase' param in the example - fixed in r417133.
Thanks,
Stepan.
Thanks!
> On 6/23/06, Stepan Mishura <st...@gmail.com> wrote:
> >
> > Hi,
> >
> > I've updated framework for testing serialization page[1] - I added
> > guidelines
> > for developing serialization tests. Also I've removed confusing
> 'TestCase'
> > parameter in SerializationTest.verifySelf() methods.
> >
> > If there are no objections I'm going in next two days to move
> > SerializationTest.java from 'security' module to support folder. So new
> > location will be:
> > support/src/test/java/org/apache/harmony/testframework/serialization
> > folder.
> > Class name won't change.
> >
> > Thoughts?
> >
> > Thanks,
> > Stepan.
> >
> > [1]
> >
> >
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
> >
> > On 6/20/06, 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)
> > > verifyGolden(TestCase, Object, SerializableAssert)
> > > verifyGolden(TestCase, Object[])
> > > verifyGolden(TestCase, Object[], SerializableAssert)
> > >
> > > 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)
> > >
> > > 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.
> > >
> > > 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: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> >
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> > ------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Andrew Zhang <zh...@gmail.com>.
Welldone stepan!
I have a small question about the sample from serialization page[1]:
public void testSerializationCompatibility()
throws Exception {
SerializationTest.verifyGolden(new SomeSerializableClass());
}
Any argument for ****.golden.ser? Typing error?
Thanks!
On 6/23/06, Stepan Mishura <st...@gmail.com> wrote:
>
> Hi,
>
> I've updated framework for testing serialization page[1] - I added
> guidelines
> for developing serialization tests. Also I've removed confusing 'TestCase'
> parameter in SerializationTest.verifySelf() methods.
>
> If there are no objections I'm going in next two days to move
> SerializationTest.java from 'security' module to support folder. So new
> location will be:
> support/src/test/java/org/apache/harmony/testframework/serialization
> folder.
> Class name won't change.
>
> Thoughts?
>
> Thanks,
> Stepan.
>
> [1]
>
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>
> On 6/20/06, 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)
> > verifyGolden(TestCase, Object, SerializableAssert)
> > verifyGolden(TestCase, Object[])
> > verifyGolden(TestCase, Object[], SerializableAssert)
> >
> > 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)
> >
> > 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.
> >
> > 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
>
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] Merging frameworks for testing serialization - first step
Posted by Stepan Mishura <st...@gmail.com>.
Hi,
I've updated framework for testing serialization page[1] - I added guidelines
for developing serialization tests. Also I've removed confusing 'TestCase'
parameter in SerializationTest.verifySelf() methods.
If there are no objections I'm going in next two days to move
SerializationTest.java from 'security' module to support folder. So new
location will be:
support/src/test/java/org/apache/harmony/testframework/serialization folder.
Class name won't change.
Thoughts?
Thanks,
Stepan.
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
On 6/20/06, 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)
> verifyGolden(TestCase, Object, SerializableAssert)
> verifyGolden(TestCase, Object[])
> verifyGolden(TestCase, Object[], SerializableAssert)
>
> 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)
>
> 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.
>
> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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