Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <4420C866.4090600@pobox.com>
Date: Tue, 21 Mar 2006 22:45:42 -0500
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of
 beans, regex and math class library code
References: <43E21900.1060508@pobox.com>
 <43F087F3.6000003@pobox.com>	 <441E3683.4030907@gmail.com>
 <441EDE83.3050701@pobox.com>
	 <fcb9f9160603200905s6dd95fag260e3292f3b2f2bb@mail.gmail.com>
	 <441EEA38.6010301@pobox.com>
	 <fcb9f9160603201328p2100d8a2p4e7aae4b99bbc6dc@mail.gmail.com>
	 <441F281C.1050901@pobox.com>
 <fcb9f9160603202341t5f9c883ai441679d19f954d25@mail.gmail.com>
 <441FE311.1090203@pobox.com> <44201B6B.2080405@gmail.com>
In-Reply-To: <44201B6B.2080405@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Tim Ellison wrote:
> Just to clarify terminology -- unit tests are a 'style' of test that
> focus on particular units of functionality.  Unit tests can be both
> implementation tests and API tests.  Implementation tests are specific
> to our implementation (the mechanism, hidden to the end user, by which
> we chose to implement the APIs); and API tests are common to all
> conformant implementations (they test the APIs used by the end user).

So can we refer to "implementation tests" as "unit tests", because I 
would bet that's a well-understood useage, and refer to things that are 
strictly testing the API as "API tests".

> 
> Geir Magnusson Jr wrote:
>> Good unit tests are going to be testing things that are package
>> protected.  You can't do that if you aren't in the same package
>> (obviously).
> 
> We have implementation tests that require package private, and maybe
> even private access to our implementation classes both in the java.* and
> o.a.h.* packages.
> 
> The 'problem' is that we cannot define classes in java.* packages that
> are loaded by the application classloader.  That is counter to
> specification and prohibited by the VM.
> 
> We also have API tests that should not have access to package private
> and even private types in the implementation.
> 
> The 'problem' is that running API tests in java.* packages does provide
> such access, and worse runs those tests on the bootclassloader which
> gives them special security access not afforded to our users.  I've said
> this lots of times before.  We already see lots of errors caused by
> oversight of the classloader differences.

Right.  And I think the solution is to think about this in some other 
way than just running things in a VM, like a test harness that does the 
right thing in terms of the classes being tested (what would be in the 
boot classloader) and the classes doing the testing.

> 
>> With the "custom" of putting in things in o.a.h.t are we
>> implicitly discouraging good testing practice?
> 
> This is laughable.

You are going to have to explain why it's "laughable".  If you are 
testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can 
you ever do implementation testing of Foo?  It's not an unreasonable 
question.  Certainly not "laughable".

> 
>> Given that this
>> o.a.h.t.* pattern comes from Eclipse-land, how do they do it?  I
>> couldn't imagine that the Eclipse tests don't test package protected
>> things.
> 
> The only thing shared with Eclipse-land here is the *.tests.* package
> name element, hardly significant or unique I expect.

Well, it is around here. While I haven't done a survey, I'm used to 
projects keeping things in parallel trees to make it easy to test. 
Granted, projects don't have the problem we have.

The thing I'm asking for is this - how in Eclipse-land do they test 
package protected stuff?  How do they do implementation tests?

> 
> Eclipse testing does not have the java.* namespace issues with
> classloaders that we have got.

Right, but that's a classloader and security manager issue for the 
testing framework, isn't it?

Hypothetically....suppose we decided (for whatever reason) that we 
weren't going to test in situ to get better control of the environment. 
  What would you do?


> 
>> I've been short of Round Tuits lately, but I still would like to
>> investigate a test harness that helps us by mitigating the security
>> issues...
> 
> Today we run all our tests in one suite on the classpath.  They are API
> tests.

I hope they are more than API tests.
> 
> I expect that we will at least have another test suite of implementation
> tests.
> 
> However, over the last few weeks we have been discussing the other
> 'dimensions' of testing that we want to embody, and we haven't settled
> on a suitable way of representing those different dimensions.  Filenames
> for testcases may do it if we can squeeze in enough information into a
> filename (I don't like that approach, BTW)

I don't either.

, or explicitly defining
> different suites of tests.

Which makes sense.

> 
> Regards,
> Tim
> 
>> geir
>>
>> Mark Hindess wrote:
>>> I thought the crucial thing was that tests should be in a separate
>>> namespace not in the namespace of the package they are testing (at
>>> least not unless it was absolutely necessary).
>>> -Mark.
>>>
>>> On 3/20/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>>> I'm doing it now.
>>>>
>>>> I need to go back and stare at our discussion on test setup, because I'm
>>>>   still not a raving fan of o.a.h.test....
>>>>
>>>> geir
>>>>
>>>> Mark Hindess wrote:
>>>>> Don't worry, you'd have to be less subtle for me to take something
>>>>> as criticism.
>>>>>
>>>>> I've had an attempt at moving beans out - HARMONY-218.  If that gets
>>>>> committed I'll do the other too.
>>>>>
>>>>> -Mark.
>>>>>
>>>>> On 3/20/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>>>>> That wasn't a criticism, btw.  It seemed like a natural thing to do
>>>>>> when
>>>>>> I first saw it, but when I was actually dealing w/ it, my opinion
>>>>>> changed.
>>>>>>
>>>>>> Yah, split away!  That was going to be my next question, how to
>>>>>> split..
>>>>>>
>>>>>> geir
>>>>>>
>>>>>> Mark Hindess wrote:
>>>>>>> Fair enough.
>>>>>>>
>>>>>>> Mind if I redo the script/patch to split the three modules to match
>>>>>>> the structure of the others?  That is, into separate modules/math,
>>>>>>> modules/beans, modules/regex directories?
>>>>>>>
>>>>>>> Regards,
>>>>>>>  Mark.
>>>>>>>
>>>>>>> On 3/20/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>>>>>>> I just committed.  There was some delay because of a missing
>>>>>>>> CCLA.  Sorry.
>>>>>>>>
>>>>>>>> I've committed the code as is from the JIRA.  I'm going to do
>>>>>>>> some basic
>>>>>>>> cleanup and then look at hte patches to integrate.
>>>>>>>>
>>>>>>>> Looking at this (and 88?) I think that this "add patches"
>>>>>>>> approach is a
>>>>>>>> bad one, because it complicates what this JIRA is now.
>>>>>>>>
>>>>>>>> In the future, I think we should just create new JIRA's for
>>>>>>>> add-ons (if
>>>>>>>> the add-on contributor isn't the contributor of the original
>>>>>>>> JIRA) and
>>>>>>>> just link them so they are easy to keep track of...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Richard Liang wrote:
>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>> Despite a touch of trouble with the packaging of the
>>>>>>>>>> contribution, it
>>>>>>>>>> passed with flying colors ( or 'colours', for our UK friends...)
>>>>>>>>>>
>>>>>>>>>> +1 from :
>>>>>>>>>>
>>>>>>>>>> Geir
>>>>>>>>>> Stefano
>>>>>>>>>> Dims
>>>>>>>>>> Tim
>>>>>>>>>> Leo
>>>>>>>>>>
>>>>>>>>>> In it comes....
>>>>>>>>>>
>>>>>>>>>> Geir Magnusson Jr wrote:
>>>>>>>>>>> I have received the ACQs and the BCC for Harmony-39, so I can
>>>>>>>>>>> assert
>>>>>>>>>>> that the critical provenance paperwork is in order (although
>>>>>>>>>>> not in
>>>>>>>>>>> SVN yet).
>>>>>>>>>>>
>>>>>>>>>>> Please vote to accept or reject this codebase into the Apache
>>>>>>>>>>> Harmony
>>>>>>>>>>> class library :
>>>>>>>>>>>
>>>>>>>>>>> [ ] + 1 Accept
>>>>>>>>>>> [ ] -1 Reject  (provide reason below
>>>>>>>>>>>
>>>>>>>>>>> Lets let this run 3 days unless a) someone states they need
>>>>>>>>>>> more time
>>>>>>>>>>> or b) we get all committer votes before then.
>>>>>>>>>>>
>>>>>>>>>>> Go...
>>>>>>>>>>>
>>>>>>>>>>> geir
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> Hello Geir,
>>>>>>>>>
>>>>>>>>> As this contribution has been accepted for a long time, I'm
>>>>>>>>> wondering
>>>>>>>>> when the source code could be put into Harmony SVN.
>>>>>>>>>
>>>>>>>>> I'm working on the implementation of java.text.DecimalFormat
>>>>>>>>> which has
>>>>>>>>> enhancements on BigDecimal and BigInteger support. Now I just
>>>>>>>>> use this
>>>>>>>>> contribution as external jars in Eclipse.
>>>>>>>>>
>>>>>>> -- 
>>>>>>> Mark Hindess <mark.hindess@googlemail.com>
>>>>>>> IBM Java Technology Centre, UK.
>>>>>>>
>>>>>>>
>>>>> -- 
>>>>> Mark Hindess <mark.hindess@googlemail.com>
>>>>> IBM Java Technology Centre, UK.
>>>>>
>>>>>
>>>
>>> -- 
>>> Mark Hindess <mark.hindess@googlemail.com>
>>> IBM Java Technology Centre, UK.
>>>
>>>
>