harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib] [testing] java.beans tests
Date Fri, 16 Jun 2006 03:21:47 GMT
Probably this method is overridden by subclasses, there are similar examples
in the classlib it's a normal practice

2006/6/16, Alexei Zakharov <alexei.zakharov@gmail.com>:
> > Alexei, it would be good if you point to a simple test that shows
> > difference in behavior, quote the spec and describe, why you think
> > Harmony does things right.
>
> The spec says about persistence delegates: "The PersistenceDelegate
> class takes the responsibility for expressing the state of an instance
> of a given class in terms of the methods in the class's public API".
>
> I don't like to worry the collective mind with details of black-box
> testing methology I use here. This is not so important. The important
> thing is the result: it seems RI version of StringPersistenceDelegate
> looks something like that:
>
> class StringPersistenceDelegate extends PersistenceDelegate {
>    ...
>    // Should be the main method of the persistence delegate.
>    // Should return the internal representation of the given
>    // java.lang.String object as a sequence of atmoic actions.
>    protected Expression instantiate(Object obj, Encoder encoder)  {
>        return null;
>    }
> }
>
> I don't belive this implementation really "express state of"
> java.lang.String instance. However, the target XML produced by
> XMLEncoder - the final result of all this activity - shows that
> strings are handled correctly by RI. I suppose they move String
> handling logic to some other place.
>
>
> 2006/6/15, Mikhail Loenko <mloenko@gmail.com>:
> > Sure we need to test protected methods and fields. Moreover we need
> > to test private methods either via API or by other means.
> >
> > Alexei, it would be good if you point to a simple test that shows
> > difference in behavior, quote the spec and describe, why you think
> > Harmony does things right.
> >
> > Thanks,
> > Mikhail
> >
> > 2006/6/14, Richard Liang <richard.liangyx@gmail.com>:
> > > Alexei Zakharov wrote:
> > > > BTW, all questionable methods of PersistenceDelegate interface are
> > > > protected rather than public. Do we need to test it at all?
> > > >
> > > Hello Alexei,
> > >
> > > IMHO, we need to test the protected methods, which are also part of API.
> > >
> > > > 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
> > > >>
> > > >
> > > >
> > >
> > > --
> > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>
> --
> 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
>
>

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