harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [classlib] Tests for serialization – which package, name?
Date Fri, 28 Apr 2006 10:39:31 GMT
On 4/28/06, Anton Avtamonov wrote:

> Stepan,
>
> I see everyone agree that we have to use the same approach accross the
> modules, but have no agreement on the particular test layout approach.
> May be you should initiate voting to choose the layout approach?
> Just to decide either to have tests in separate packages, separate
> TestCases or together with tests for other methods?


Anton, I still hope to convince you :-) Also this discussion helps me to
understand consequences if we choose your way of creating tests. I've
summarized your suggestions with Richard's and created new test example. Now
it looks like the following:

public class MyTest extends TestCase {

    // No original setUp()/tearDown()  because they don't relates to
serialization testing!!!

    public void mySetUp() throws Exception { }
    public void myTearDown() throws Exception {}

     public void testSomethingUnrelatedToSerialization() throws Exception {
         mySetUp() ;
         try {
             ... code ...
         } finally {
             myTearDown();
         }
     }

     public void testCtor() throws Exception {
         mySetUp() ;
         try {
             ... code ...
         } finally {
             myTearDown();
         }

     }

     public void testSerialization(){
        assertTrue(SerializationTester.assertEquals(new My(param1, param2,
param3)));
        assertCompabilityEquals(new My(param1, param2, param3), "test1.ser
"),

        assertTrue(SerializationTester.assertEquals(new My(param4, param5,
param6)));         assertCompabilityEquals(new My(param4, param5, param6), "
test2.ser"),

        assertTrue(SerializationTester.assertEquals(new My(param7, param8,
param9)));         assertCompabilityEquals(new My(param7, param8, param9), "
test3.ser"),
     }
}

So is this your way?

Thanks,
Stepan.


> Wishes,
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
>
> On 4/28/06, Richard Liang <richard.liangyx@gmail.com> wrote:
> > Stepan Mishura wrote:
> > > On 4/28/06, Anton Avtamonov wrote:
> > >
> > >> On 4/28/06, Stepan Mishura wrote:
> > >>
> > >>> On 4/28/06, Anton Avtamonov wrote:
> > >>>
> > >>>> On 4/28/06, Stepan Mishura wrote:
> > >>>>
> > >>>>> On 4/27/06, Anton Avtamonov  wrote:
> > >>>>>
> > >>>> <SNIP>
> > >>>>
> > >>>> 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:
> > >>>>
> > >>> Anton, when you override setUp() and tearDown() methods you also
> don't
> > >>>
> > >> see
> > >>
> > >>> how and where they are used. Do you use them or copy/paste
> > >>>
> > >> setUp/tearDown
> > >>
> > >>> code to every testing method?
> > >>>
> > >> That's why setUp() should do something very common for all the tests
> > >> in the TestCase. All "test specific" customizations go to test
> > >> methods.
> > >>
> > >> Actually, no reasons to argue about minor design specifics: all of
> > >> them work. What to prefer is very individual as I said. I don't
> expect
> > >> consensus here :-).
> > >>
> > >
> > >
> > > A lot of copy/pased tests.
> > >
> > > I use delegation when possible just because of better flexibility. If
> > >
> > >> we want to discuss design and Design Patterns aspects (especially how
> > >> and where inheritance or delegation should be used) we can create a
> > >> separate thread :-).
> > >>
> > >> The idea is that both separating and mixing of the serialization
> tests
> > >> can be done. The original question is: what do we want. Definitely,
> > >> both approaches can be implemented.
> > >>
> > >
> > >
> > > Yes, it is possible to implement any number of approaches - luni
> module will
> > > use one approach, security module will use another approach, beans
> will use
> > > the third one. But it would be better to select one approache and
> follow it
> > > to make development/support easier and simple.
> > >
> > >
> > I strongly recommend that all modules use the same approach. ;-)
> > > Thanks,
> > > Stepan Mishura
> > >
> > > ------------------------------------------------------
> > > 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
> >
> >
>
> --
> 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

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