You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexei Zakharov <al...@gmail.com> on 2006/06/14 14:26:42 UTC
[classlib] [testing] java.beans tests
Hello to everyone,
I am currently investigating tests for java.beans module. 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.
For point 2, I believe we should rewrite or delete such tests.
Thoughts, suggestions?
--
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
Re: [classlib] [testing] java.beans tests
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Alexei Zakharov wrote:
> Hello to everyone,
>
> I am currently investigating tests for java.beans module. 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.
Yes. Agreed.
> For point 2, I believe we should rewrite or delete such tests.
>
> Thoughts, suggestions?
As Mikhail and Tim suggested, lets get a list of the failures, the
reasons, and deal with them as they come. It's drudge work, but we need
to be sure our implementation not only passes the TCK, but also works
like users expect, which sadly includes oddities of the RI.
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
Re: [classlib] [testing] java.beans tests
Posted by Mikhail Loenko <ml...@gmail.com>.
Probably this method is overridden by subclasses, there are similar examples
in the classlib it's a normal practice
2006/6/16, Alexei Zakharov <al...@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 <ml...@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 <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Alexei Zakharov <al...@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 <ml...@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 <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Alexei Zakharov <al...@gmail.com>.
Agree. So, I'm going to rewrite the tests to reflect currently
implemented architecture if no objections.
2006/6/19, Mikhail Loenko <ml...@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 <al...@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 <ml...@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 <al...@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 <ml...@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 <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Mikhail Loenko <ml...@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 <al...@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 <ml...@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 <al...@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 <ml...@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 <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Alexei Zakharov <al...@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 <ml...@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 <al...@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 <ml...@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 <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Mikhail Loenko <ml...@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 <al...@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 <ml...@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 <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/6/16, Alexei Zakharov <al...@gmail.com>:
> To test RI's private methods you need to know the fact of their
> existence at least.
I'm not saying we need to test RI's private methods. But our tests should
test that our private methods work according to our design
Thanks,
Mikhail
---------------------------------------------------------------------
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
Re: [classlib] [testing] java.beans tests
Posted by Alexei Zakharov <al...@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 <ml...@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 <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Mikhail Loenko <ml...@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 <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Richard Liang <ri...@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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Alexei Zakharov <al...@gmail.com>.
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 <al...@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....@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
Re: [classlib] [testing] java.beans tests
Posted by Alexei Zakharov <al...@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....@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
---------------------------------------------------------------------
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
Re: [classlib] [testing] java.beans tests
Posted by Tim Ellison <t....@gmail.com>.
p.s. the reference to [1] is
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Tim Ellison wrote:
> 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
>
--
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
Re: [classlib] [testing] java.beans tests
Posted by Tim Ellison <t....@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
--
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
Re: [classlib] [testing] java.beans tests
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Alexei
2006/6/14, Alexei Zakharov <al...@gmail.com>:
> Hello to everyone,
>
> I am currently investigating tests for java.beans module. As far as I
Cool!
> 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.
Please publish all those differences, we will need to make decisions on
case-by-case basis.
> For point 2, I believe we should rewrite or delete such tests.
If once you rewrite a test you get a duplicate of another test then
the test might be
deleted. Otherwise it should be fixed.
Thanks,
Mikhail
>
> Thoughts, suggestions?
>
>
> --
> 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