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 Mon, 19 Jun 2006 09:01:02 GMT
Agree. So, I'm going to rewrite the tests to reflect currently
implemented architecture if no objections.


2006/6/19, Mikhail Loenko <mloenko@gmail.com>:
> Alexei
>
> in this case we should test that those method work exactly as we designed them.
> (so, test it not from a user prospective but from developer's perspective)
>
> Thanks,
> Mikhail
>
>
> 2006/6/16, Alexei Zakharov <alexei.zakharov@gmail.com>:
> > MIkhail,
> >
> > I fully agree that we need to test protected methods of public classes
> > - java.beans.PersistenceDelegate for example. But I was talking about
> > a bit different thing - testing children of PersistenceDelegate that
> > are NOT public API classes. But we still need to implement it somehow.
> > User is allowed to call protected methods of such classes only in two
> > abnormal cases I explained previously. The question is: should we care
> > about such things or not.
> >
> > 2006/6/16, Mikhail Loenko <mloenko@gmail.com>:
> > > A user might have one's own "com.foo.HisStringPersistenceDelegate" extending
> > > java.beans.PersistenceDelegate and that class might invoke
> > > "protected void initialize()" from the super class.
> > >
> > > If our and RI's initialize work differently then we are in trouble
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/6/16, Alexei Zakharov <alexei.zakharov@gmail.com>:
> > > > To test RI's private methods you need to know the fact of their
> > > > existence at least.
> > > >
> > > > As for protected methods, I agree in general. We need to test it and
> > > > to follow the behavior of RI. But in this particular case with
> > > > java.beans.PersistenceDelegate I am not 100% sure this makes much
> > > > sense.
> > > >
> > > > Ok, let's be more specific. About how can we test it. We have the
> > > > following picture here:
> > > >
> > > > <===
> > > >
> > > > package java.beans;
> > > > public abstract class PersistenceDelegate {
> > > >    protected void initialize(..) {...}
> > > >    protected abstract Expression instantiate(...);
> > > >    ...
> > > > }
> > > >
> > > > package com.blah.blah.beans;
> > > > class MyStringPersistenceDelegate extends java.beans.PersistenceDelegate
{
> > > >    protected void initialize(..) {
> > > >        // does some implementation-specific stuff
> > > >    }
> > > >
> > > >    protected Expression instantiate(...) {
> > > >         ...
> > > >         // returns propriatery representation of String in terms of
> > > >         // java.beans.Expression
> > > >    }
> > > > }
> > > >
> > > > package java.beans;
> > > > public class Encoder {
> > > >    public PersistenceDelegate getPersistenceDelegate(Class type) {
> > > >        if (type.equals(String.class)) {
> > > >           return new com.blah.blah.beans.MyStringPersistenceDelegate();
> > > >        }
> > > >    ...
> > > >    }
> > > >    ...
> > > > }
> > > >
> > > > <===
> > > >
> > > > Now we like to understand how user is affected if our implementation
> > > > of MyStringPersistenceDelegate differs from RI. The user can do
> > > > something like
> > > >
> > > > Encoder enc = new Encoder();
> > > > PersistenceDelegate pd = enc.getPersistenceDelegate(String.class);
> > > > Expression exp = pd.instantiate(...);
> > > >
> > > > from his/her code. (NOTE: this is the only way the user can be
> > > > affected by persistence delegates.)
> > > > But, this will work only in two cases:
> > > > 1) The user extends MyStringPersistenceDelegate. But since this class
> > > > is the RI internal class with arbitrary name this will not work on
> > > > Harmony anyway because we most likely use different class names for
> > > > internal classes.
> > > > 2) The user extends java.beans package with additional class. This can
> > > > happen. But this is not a recommended practice. Such a user probably
> > > > should know what he/she is doing and be ready to face with problems.
> > > >
> > > > So I'm not sure if we should care about these cases.
> > > >
> > > > I will write in the separate message why I don't like RI's
> > > > StringPersistenceDelegate and why IMHO Harmony "does things right".
> > > >
> > > >
> > > > 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
> > >
> > >
> >
> >
> > --
> > 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
>
>


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