harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: local test server (Was: Re: [jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError)
Date Thu, 23 Feb 2006 10:19:54 GMT
Just want to emphasise something that has possibly got lost in this 
thread. To date, all of the discussion on this topic seems to have been 
based on "eye balling" of the code in issue HARMONY-57. It would almost 
certainly help move things forward if people were to start actually 
running the tests (particularly those pesky java.net.* ones).

Once people start running these tests we can discuss experiences of 
set-up etc and work to *evolve* them into something more suitable to the 
needs of the Harmony development community. It's only natural that 
improvements in test coverage, test quality and test 
complexity/simplicity are going to occur. The simpler it is to set up 
and run the tests, the better for all of us. My own comments on this 
thread have been mainly focussed about what is actually there *today* in 
HARMONY-57 ; it would be great to move up to discussions on the running 
tests and then for us all to participate in their evolution.

My 2 Euro Cents.


George Harley wrote:
> Mark Hindess wrote:
>> I think it might help this disagreement if we step back and decide
>> what scenarios for running tests we are trying to optimise.
> Disagreement ? What ? On this mailing list ? :-)
>> Personally, whenever I write tests I'm doing it to optimise the
>> scenario where a new users comes to the project and does:
>> 1$ svn co ... classlib # or wget/tar if you prefer
>> 2$ cd classlib/make
>> 3$ ant test
>> I do this because I want the tests to be easy to run by new users
>> particularly on new platforms.  I hope making it this easy means we
>> get more people running tests and that we get a broader set of results
>> than we could acheive ourselves.
>> This scenario becomes slightly less pleasant if, between steps 2 and
>> 3, [*] you have to find your nearest Linux machine and install Apache
>> httpd, your-favourite-ftp-server, Dante socks server, etc.  This
>> typically means that I'd be inclined to write stub servers to test
>> against.
>> But this doesn't mean George is wrong!  Because *if* there was a
>> publically accessible Internet server that already had Apache httpd,
>> twoftpd (my favourite ftp server this week), Dante socks, etc, then
>> the scenario I like to optimise becomes possible.  The effort of
>> setting up one hosting server is definitely cheaper than the effort of
>> implementing stubs - I know because I set up the server George tests
>> against and it didn't take much time at all.
> Agreed : a central, publicly available test server that could be used 
> for network-related testing would IMHO be advantageous to us all. I 
> wonder if such a server can be supplied through the auspices of the 
> ASF ? Incidentally, it took me only a small amount of time to set up 
> my laptop for running the tests on locally.
>> Having one server means we wont get 1000's of users asking Apache
>> httpd, twoftpd, Dante socks configuration questions on our mailing
>> lists.  It also means we have a way to see the other half of the
>> results - that is, the server logs.  (Stubs should make this easier
>> and this cost should be considered too but if we ran the server we
>> could make this easier.)
>> George's approach continues to be cheaper even if a few groups have to
>> set up there own servers - though I think the set of users who "don't
>> have Internet access but do have a mechanism for getting up to date
>> Harmony code" should be small and getting smaller.  Of course, it
>> becomes much more expensive if everyone has to do it.
> Agreed.
>> I've never tried using George's approach on past projects because I've
>> either also been writing server code, that can/should be used by
>> tests, or because the server was massive and I didn't have the
>> experience or resources to run a real server.  Because of this,
>> initially, I was inclined to support the implemention of stubs, but
>> now I'm not so certain.
>> I think it basically comes down to whether or not we can provide a
>> central server.  I'm not sure it's a simple question but for me this
>> question is key to this issue.
>> Or perhaps I'm optimising for the wrong scenario?
>> Regards,
>>  Mark.
>> [*] More likely people would run step 3 find it goes horribly wrong
>>     then read the README they ignored initially and discover why. ;-)

View raw message