harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [classlib] [testing] java.beans tests
Date Wed, 14 Jun 2006 15:02:26 GMT
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


Mime
View raw message