RE: [classlib] trying new framework for testing serialization
> -Original Message- > From: Stepan Mishura [mailto:[EMAIL PROTECTED] > > * 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
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:[EMAIL PROTECTED] > 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 Te
RE: [classlib] trying new framework for testing serialization
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:[EMAIL PROTECTED] > 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, > > > > > > > > > > > > > > 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. > > > > > > > > > > > &
Re: [classlib] trying new framework for testing serialization
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 <[EMAIL PROTECTED]> 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, > > > > > > > > > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
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, > > > > > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
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 <[EMAIL PROTECTED]> wrote: On 6/30/06, Jimmy, Jing Lv wrote: > > Stepan Mishura wrote: > > Hi Jimmy, > > > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib] trying new framework for testing serialization
On 6/30/06, Jimmy, Jing Lv wrote: Stepan Mishura wrote: > Hi Jimmy, > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization (was:Merging frameworks for testing serialization - first step)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] trying new framework for testing serialization (was:Merging frameworks for testing serialization - first step)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]