harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] jetty based tests
Date Tue, 23 May 2006 17:35:19 GMT
This thread was a long read :)

First,  I'm all for using Jetty as our test server (I think we talked 
about this a long time ago...).  We could even use Tomcat, but my 
experience in the past was that Jetty was very easy to emebed.  By 
default, there should be no external dependency to build, test and run 
Harmony (i.e. I can do it on a plane - that means that no external 
server is required.)

Second, I think that we don't lose much in terms of flexibility, and 
gain an awful lot in functionality.  Writing tests is very easy, and we 
probably can control anything we want to for custom stuff.

Third, we get location transparency.  Our isolated-system-default 
notwithstanding, we certainly want to test over a network (localhost 
doesn't cut it), so we should easily be able to run the ant target that 
runs the server on a remote machine so we can test things like real 
network failure and interruption (IOW, reach around and pull the network 
cable out...), setting a property or -ish for the address of the test 
target server (default is localhost)

Given that the argument is long and winding, can people do a checkpoint 
summary about how they are feeling?

geir

Stepan Mishura wrote:
> On 5/23/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> 
>> Hi, Stepan,
>>
>> "No we shouldn't write a mock http server for each case (I mean that we
>> need
>> not implement http protocol each time)."
>>
>> Shall we implement http sometimes? If no, how can we verfiy
>> HttpURLConnection function, for example, whether the request is in http
>> format,
>> or chuncked http request.
> 
> 
> Yes we have implement http protocol in HttpURLConnection class. The 
> question
> is how to verify its implementation. This can be done in two ways: with or
> without existing http server. Both ways are possible. Approach with using
> existing http server for testing looks more confident but misuse of this
> approach may result in hard-to-configure and slow-to-run test suite. So my
> position was that we can use both ways but separately. Tests that don't
> depend on http server are included in 'normal test suite' and run 
> regularly.
> And dependant tests are run separately.
> 
> But if jetty is so good as George and Paulex described then I'll think 
> about
> revising my position.
> 
> 
> 
>> If there's a mock httpserver utility, which could assert whether 
>> receieved
>> http request is correct, and could generate customized http output, it 
>> can
>> be called "little jetty". If the utility httpserver could customize 
>> output
>> more flexibility, could make some unspecial output which jetty couldn't,
>> it
>> could be called "enhanced jetty". Finally, the utility class will have to
>> implement http protocol and become an HttpSrever or
>> EnhanceedHttpServer(since it could do some extra work, e.g, produce 
>> broken
>> http response, etc.).
>>
>> "So we have to develop mock server anyway. And the mock server can be 
>> used
>> for other ('positive') tests. Right? Then why we have to use jetty?"
>>
>> If there's a mock server utility can be easily used for normal and
>> abnormal
>> http test, I've no objection to use it.
>> At least, we have one in common: reduce external dependency. Right?
> 
> 
> Yes
> 
> Thanks,
> Stepan.
> 
> 
> 
> 
> 
>> Thanks.
>>
>>
>> On 5/23/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
>> >
>> > On 5/23/06, Andrew Zhang wrote:
>> > >
>> > > Hi, Stepan,
>> > >
>> > > "With mock objects this can be done with no problems and HARMONY-164
>> > > demonstrates the possible way."
>> > >
>> > > Shall we write a mock http server for each case?  It takes lots of
>> > > reduplicate efforts and results in many mock http server classes in
>> the
>> > > end.
>> >
>> >
>> > No we shouldn't write a mock http server for each case (I mean that we
>> > need
>> > not implement http protocol each time). In "HARMONY-164 version" mock
>> > server
>> > is an instance of class that extends Thread class. The mock server is
>> > started before running test and by default is just listens for incoming
>> > connection. A test has access to server's instance and may configure it
>> > response (I didn't implemented but it is also possible to save request
>> to
>> > be
>> > verified). There is no http protocol implementation.
>> >
>> > In fact, for many regular tests, jetty works fine.
>> > >
>> > > And I also agree that for negative tests and some other special tests
>> > > which
>> > > jetty could not satisfy ,  we should use mock http server instead.
>> >
>> >
>> > So we have to develop mock server anyway. And the mock server can be
>> used
>> > for other ('positive') tests. Right? Then why we have to use jetty?
>> >
>> > Thanks,
>> > Stepan.
>> >
>> > What's your opnion?
>> > >
>> > > Thanks.
>> > >
>> > >
>> > > On 5/23/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
>> > > >
>> > > > Hi George, Tim
>> > > >
>> > > > I'd like to clarify the following questions:
>> > > > 1) Configuring
>> > > > As I understood we say that the server is 'embedded' when we can
>> > > > start/stop
>> > > > it within Ant without additional configuration steps. And all we
>> need
>> > to
>> > > > do
>> > > > is just download required jars. Right?
>> > > >
>> > > > What about Eclipse users?
>> > > >
>> > > > 2) Time to run test suite
>> > > > May be it is hard to estimate but anyway - will the test suite run
>> > slow
>> > > > down
>> > > > if we'll use jetty instead of mock objects? How much?
>> > > >
>> > > > 3) Testing
>> > > > Quoting Tim from 'local server thread': "There is no way to force
a
>> > > server
>> > > > to send you a chunked response using regular HTTP headers, so in
>> this
>> > > case
>> > > > the server and client have an understanding that when the client
>> asks
>> > > for
>> > > > a
>> > > > particular resource the server will send it back in chunks."
>> > > >
>> > > > With mock objects this can be done with no problems and HARMONY-164
>> > > > demonstrates the possible way. Also are we going to create negative
>> > > tests,
>> > > > for example, for broken server response? I think yes. Can jetty
>> server
>> > > be
>> > > > used for negative testing?
>> > > >
>> > > > See other comments below
>> > > >
>> > > > On 5/22/06, George Harley wrote:
>> > > > >
>> > > > > Stepan Mishura wrote:
>> > > > > > On 5/19/06, Tim Ellison wrote:
>> > > > > >>
>> > > > > >> Stepan Mishura wrote:
>> > > > > >> <snip>
>> > > > > >> > I'm OK only if we separate tests with Jetty from
common test
>> > > suite
>> > > > > >> run.
>> > > > > >>
>> > > > > >> Why?
>> > > > > >
>> > > > > >
>> > > > > > Because each external dependency complicates 'normal' test

>> suite
>> > run
>> > > (
>> > > > I
>> > > > > > don't want to face with situation when to run Harmony test

>> suite
>> I
>> > > > > > have to
>> > > > > > configure and run 20 different external servers even they
are
>> easy
>> > > > > > configurable). As far as I remember we agreed to use mock
>> objects
>> > -
>> > > so
>> > > > > > let's
>> > > > > > use them! For example, in this case there is no need in
jetty
>> > > server.
>> > > > > >
>> > > > > > I'm not against 'jetty based tests' but I'd prefer to separate
>> > such
>> > > > > > tests.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Stepan.
>> > > > > >
>> > > > >
>> > > > > Hi Stepan,
>> > > > >
>> > > > > Just seen this note and think that my previous append on the
"Re:
>> > svn
>> > > > > commit: r407752" thread sums up my thoughts. Allow me to quote
>> > myself:
>> > > > >
>> > > > > <paste>
>> > > > > Jetty or equivalent is a good basis for such local server stubs.
>> It
>> > is
>> > > > > fast, it is lightweight,
>> > > >
>> > > >
>> > > > Fast and lightweight as what?
>> > > > I saw sometimes ago java server that has jar size 4k. And
>> > > > jetty-6.0.0beta6.jar is 423k size.
>> > > >
>> > > >
>> > > > > it can be started and stopped very simply from
>> > > > > within Ant (so that it only runs for the duration of a specified
>> > batch
>> > > > > of unit tests) and may also be completely controlled from Java
>> test
>> > > code
>> > > > > so that we can configure its behaviour for any test case from
>> within
>> > > > > that test case.
>> > > >
>> > > >
>> > > > Good.
>> > > >
>> > > > It's architecture means that we do not have to run it as
>> > > > > a complete web server but can stub out any aspect of its runtime
>> > > > > behaviour we wish in order to suit the purposes of the test(s).
>> > > >
>> > > >
>> > > > What about 'chunked response'? Can a testcase force jetty server to
>> > send
>> > > > it
>> > > > a chunked response?
>> > > >
>> > > > I don't really understand why such network tests making use of a
>> > small,
>> > > > > embedded server running locally would need to be considered as
>> > outside
>> > > > > of the "normal test flow".
>> > > > > </paste>
>> > > >
>> > > >
>> > > > Because I consider adding jetty server as precedent for adding 
>> other
>> > > > dependencies to the "normal test flow". I believe that "normal test
>> > > flow"
>> > > > should be fast and lightweight as much as possible. Each additional
>> > > > dependency or configuration step adds a brick(even it light) to
>> > > > developer's
>> > > > large. As the result classlib test suite may become very slow and
>> hard
>> > > to
>> > > > configure. All I want is to understand - do we really need jetty
>> > server
>> > > > inside it.
>> > > >
>> > > > Thanks,
>> > > > Stepan.
>> > > >
>> > > > We are not talking about an external server here and we are not
>> > talking
>> > > > > about developers having to carry out complex configuration
>> > manoeuvres
>> > > > > when running the tests. That is something that nobody wants.
The
>> > > > > motivation here is purely to get more of the java.net tests 
>> out of
>> > the
>> > > > > "excludes" sin bin.
>> > > > >
>> > > > > Best regards,
>> > > > > George
>> > > > >
>> > > > >
>> > > > > > 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
> 


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