harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib] [testing] java.beans tests
Date Wed, 14 Jun 2006 14:46:22 GMT
BTW, all questionable methods of PersistenceDelegate interface are
protected rather than public. Do we need to test it at all?

2006/6/14, Alexei Zakharov <alexei.zakharov@gmail.com>:
> Mikhail, Tim,
>
> > I suggest that you raise a few examples here.
>
> The first example that comes to my mind is the RI's implementation of
> PersistenceDelegate for java.lang.String class. (Persistence delegate
> is a class that manages persistence details of his target class and is
> used by java.beans.XMLEncoder). RI's imeplementation just does nothing
> and returns null there applicable. It seems that RI guys simply
> created a stub class they do not actually use. Most likely they
> embedded String-handling logic in some other place in code. IMHO such
> a decision doesn't fully correspond the idea of persistence delegates
> as a place for persistence-handling logic.
>
> BTW, our StringPersistenceDelegateTest (point 2 in my classification)
> also expects some non-stub behavior from StringPersistenceDelegate. It
> seems that people who have created this test also don't like this
> aspect of the RI's implementation. :)
>
> 2006/6/14, Tim Ellison <t.p.ellison@gmail.com>:
> > Alexei Zakharov wrote:
> > > Hello to everyone,
> > >
> > > I am currently investigating tests for java.beans module.
> >
> > Great.
> >
> > > As far as I
> > > understand there were two separate contributions of java.beans tests
> > > from two different parties. And these contributions were merged into
> > > the single combined test suite we have now in svn. As a result
> > > currently we have about 400 test case failures (excluded) out of
> > > approximately 1200. After spending some time on this I realize that we
> > > have two types of issues here:
> > >
> > > 1. Test checks the compliance with very deep detail of RI's behavior (that
> > > is not in spec).
> > > 2. Test expects the behavior that differs from the RI's behavior as well as
> > > from our implementation's behavior.
> > >
> > > As for point 1, I'm unsure here. Do we really need to be completely
> > > identical to the RI in terms of public methods behavior? Some RI
> > > decisions are strange.
> >
> > We need to work the same (possibly unspecified) way as the reference
> > implementation to ensure compatibility for Java apps.  An example of
> > some areas we already thought about are listed here [1].
> >
> > If the decision is strange so that you think it is bug then we may
> > choose to depart from the RI's behavior after discussion on this list,
> > but if it is wrong because you disagree with the approach, then I'm
> > afraid that compatibility wins <g>.  I suggest that you raise a few
> > examples here.
> >
> > > For point 2, I believe we should rewrite or delete such tests.
> >
> > Agreed -- please indicate with your JIRA patch why you think they are
> > wrong, and that will help people review you rewrite/deletion request.
> >
> > > Thoughts, suggestions?
> >
> > I'm happy that you are looking into this, and look forward to your patches!
> >
> > Regards,
> > Tim
>
> --
> Alexei Zakharov,
> Intel Middleware Product Division
>


-- 
Alexei Zakharov,
Intel Middleware Product 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
View raw message