Stepan Mishura wrote:
On 4/28/06, Paulex Yang wrote:
Paulex Yang wrote:
<SNIP>
I think two serialization test is necessary in general:
1. test for Harmony itself, which ensure that the object can be
serialized/deserialized smoothly within Harmony VM/classlib
2. test for compatibility with RI, which ensure that the object
serialized by RI can be deserialized by Harmony smoothly, and vice
versa.
The sample I mentioned is only for case 1. And if I understand you
clearly, your concern is about case 2, for which, there is a
test_serializationCompatibility() method in [2].
And the SerializationTester[1] provide a helper method named as
assertCompabilityEquals(Object obj, String fileName), which will
deserialize object from give file (supposing it's the golden file
generated by RI), compare with given Object and return result.
I missed one thing just now, because currently we only run testcases on
Harmony, currently these testcass only cover half of case 2 -
deserialized bytes generated by RI in Harmony. And if we start to run
testcase on RI someday, we can try some straight forward modification to
support the other part.
Raulex, if you someday will want to add new option/capability to
serialization testing it will be not trivial task to do if serialization
tests are mixed with other tests.
Stepan,
I think there are two issues:
1. mixed/separated serialization tests
2. two serialization frameworks
I consider the adding new option/capability is more a framework issue
than mixed/separation. And we need to discuss how we merge our
serialization tests into unified framework. But as you mentioned, that's
next topic.
About the sperated/mixed tests, I just consider many serilization test
codes are too trivial to be separated as a unique class( by referring
some code sample ).
Thanks,
Stepan.
Thanks,
Mikhail
[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/util/SerializationTester.java?rev=386058&view=log
[2]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/util/IllegalFormatCodePointExceptionTest.java?rev=396023&view=markup
I don't think that having ser tests separated is a bad idea, however
having an additinal test file with one-two methods only for each api
class looks like a bit 'expensive' approach.
Thanks,
Mikhail
2006/4/27, Stepan Mishura <[EMAIL PROTECTED]>:
Hi,
I'd like to discuss naming conventions for serialization tests -
does it
make sense to separate serialization tests from unit tests?
For example, in module security tests for serialization were
placed into
separate packages:
java.security.serialization
java.security.cert.serialization
java.security.spec.serialization
Also it is possible to put tests in the same package but name
them in
different ways, for example,
SomeClassTest.java – unit test for SomeClass
SerSomeClassTest.java – serialization test for SomeClass
Or we won't separate serialization tests from unit tests and will
test
serialization by adding corresponding methods to unit test, for
example,
public void testSerialization1()
public void testSerialization2()
public void testSerialization3()
public void testSerializationCorrupted()
public void testSerializationIllegalValues()
Thoughts?
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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Anton Avtamonov,
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]
--
Paulex Yang
China Software Development Lab
IBM
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
