On 4/28/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> On 4/27/06, Anton Avtamonov wrote:
>
> > On 4/27/06, Tim Ellison wrote:
> > > I say leave them mixed. We are no more likely to want to run
> > > serialization tests separately than we are locking tests etc. and trying
> > > to layout the tests on disk to represent all the different metadata
> > > about each test case is not going to work.
> >
> > +1. usually we have test layout like: one class - one TestCase. I
> > don't see big reason to support several layouts simultaneously
> > (class-based, serialization-based, etc.)
>
>
> Agree, "one class - one TestCase" it's a good formula in general.
> But I'd prefer separate tests to verify standalone functionality (BTW, there
> a separate spec. for serialization!).
Well, the spec describes how and which private fields/methods can be
defined to handle serialization, right? So, to test serialization spec
we should use special tests which cover serialization engine itself.
As I told already that is not a case for object serialization testing
which just ensure that object is properly restored.
> Separating makes possible to unify
> testing approach that in turn leads to more simple and effective tests, for
> example, which tests looks better?
>
> public class SerMyTest extends SerializationTest {
> protected Object[] getData() {
> return new Object[]{
> new My(param1, param2, param3),
> new My(param4, param5, param6),
> new My(param7, param8, param9),
> };
> }
>
> protected void assertDeserialized(Object oref, Object otest) {
> //override to provide specific comparison
> }
> }
>
> public class MyTest extends TestCase {
>
> public void setUp() throws Exception {
> // sophisticated set up that unrelated to serialization at all !!!
> }
> public void tearDown() throws Exception {
> // sophisticated tear down that unrelated to serialization at all
> !!!
> }
>
> public void testSerialization1(){
> ObjectInputStream in = new
> ObjectInputStream(getClass().getResourceAsStream(
> "test1.ser"));
> My my = (My) in.readObject();
> assertEquals(new My(param1, param2, param3), my);
> }
>
> public void testSomethingUnrelatedToSerialization() {
> }
>
> public void testSerialization2(){
> ObjectInputStream in = new
> ObjectInputStream(getClass().getResourceAsStream(
> "test2.ser"));
> My my = (My) in.readObject();
> assertEquals(new My(param4, param5, param6), my);
> }
>
> public void testCtor() {
> }
>
> public void testSerialization3(){
> ObjectInputStream in = new
> ObjectInputStream(getClass().getResourceAsStream(
> "test3.ser"));
> My my = (My) in.readObject();
> assertEquals(new My(param7, param8, param9), my);
> }
> }
Which approach is better is very personal :-). I would ay that the
second one. It is more intention-revealing. Really, when you override
testDeserialized() you don't see how and where it is used. With
properly used delegation pattern the tests would be:
testSelfSerialization() {
Object deserialized = SerializationTest.serializeDeserialize(original);
assertEquals(original, deserialized);
}
In case deserialization assertion for the particular object is not
just assertEquals() it will be well-shown.
Similarly to test against stored serialization form (golden file).
Wishes,
--
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]
