Geir Magnusson Jr wrote:
> 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?
Does 'exhausted' count ;-)
FWIW I also agree that using Jetty embedded in the tests is a good idea,
with custom handlers etc. to force some test case scenarios. Where it
doesn't work we can do stubs.
I assume that we can have a test script config file to define the server
location. We can have the default mode be starting the Jetty server on
localhost (a.k.a. 'airplane mode' <g>), then if you want to run the
server remotely the tests config would have to be updated...
Regards,
Tim
> geir
>
> Stepan Mishura wrote:
>> On 5/23/06, Andrew Zhang <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
>>> > > > > >> IBM Java technology centre, UK.
>>> > > > > >>
>>> > > > > >>
>>>
>>>
>>
>> ------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
