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 04:51:23 GMT
So if you fix bug in java.io.ObjectInputStream then you have to run all
tests for all modules because tests for serialization mixed with other
tests. Are you OK with this?

Thanks,
Stepan

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.
>
> Regards,
> Tim
>
> Stepan Mishura wrote:
> > On 4/27/06, Geir Magnusson Jr  wrote:
> >>
> >>
> >> Stepan Mishura wrote:
> >>> Hi,
> >>>
> >>> I'd like to discuss naming conventions for serialization tests - does
> it
> >>> make sense to separate serialization tests from unit tests?
> >> I actually don't know.  What are the pros/cons?
> >
> >
> > I'd propose to separate them. It seems to me that this approach more
> > manageable and flexible, for example, we may wish in future to move
> > serialization tests into separate test suite or we can select to run
> tests
> > for serialization only, for example, if we update/improve serialization
> > framework. Also we may put(force) some requirements how should test for
> > serialization should like. This will unify serialization tests (for
> example,
> > it may be done in a way like SerializationTest does or any other way.
> Right
> > now I wouldn't want to argue whether it is good to create super class to
> be
> > extended by test or not - it will be the next topic :-).)
> > In case if we mix testing serialization functionality with tests for API
> > methods then we won't have such opportunities.
> >
> > So the question was: does it make sense to keep serialization test
> separate
> > or everybody OK with mixing them with unit tests for API methods?
> >
> > Thanks,
> > Stepan.
> >
> > geir
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
> --
>
> 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
>
>


--
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