harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: local test server (Was: Re: [jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError)
Date Mon, 06 Mar 2006 07:07:01 GMT
On 3/3/06, Geir Magnusson Jr <geir@pobox.com> wrote:
<...snip...>
>> I believe this approach may be applied for most of cases and allow us to
>> eliminate dependency on an external server.
>
>And give us tight control to be able to mimic misbehavior on the server
>side to be sure that the library behaves correctly.
>

Sure, it is quite important to verify that the implementation functions
properly in case of incorrect server's respond. And this can not be tested
with a 'real' server because as was noted previously "there is no way to
force a server to send you a chunked response using regular HTTP headers". I
can add that there is no way to force a server to send you a corrupted
respond.

 <...snip...>
>
>I took a quick look, and while I really am convinced that our own
>framework is necessary for all sorts of reasons I and others have listed
>already, I do wonder if we could simply do better via using jetty or
>tomcat in some way?
>

Sorry, I didn't catch your suggestion with using jetty or tomcat. I don't
understand the next: why we should introduce external dependency when there
is simple solution?
When I see that a complicated way is invented instead of using simple and
obvious (from my point of view) solution I always assume two options here:
- I missed something important and someone should point me out where I'm
wrong.
- A person tends to create sophisticated solutions due to some reasons, for
example, she/he worked with some http server for years and now believes that
it should be used everywhere.

Returning back to our case, I do believe that there must be strong arguments
for using external server for unit testing. Arguments like a server is free
and easy configurable don't work against 40 lines of code and absence of
special configuration.

Thanks,
Stepan


On 3/3/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>
>
>
> Stepan Mishura wrote:
> > Tim, George, I'd like to resume this topic
>
> Thanks for posting to the dev list :)
>
> >
> >> 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.
> >>
> >
> > I've created a small local server that just demonstrates common approach
> > only. The idea is the next: a simple local server provides a way for a
> unit
> > test to configure a server's response (also it may be improved to save a
> > request message to be check by a unit test):
> >               ---invoke--->            ---request--->
> > A unit tests            tested API             a local server instance
> >     |         <---result---            <---response---   ^
> >     |                                                              |
> >      -------------------configure server--------------------
> >
> > I believe this approach may be applied for most of cases and allow us to
> > eliminate dependency on an external server.
>
> And give us tight control to be able to mimic misbehavior on the server
> side to be sure that the library behaves correctly.
>
> >
> > I've created JIRA (see Harmony-164) and attached a file with local
> server
> > and 2 JUnit test cases (one of them sends a chunked response, please
> note
> > there is no server's code specific for a selected test). Could you
> please
> > review the code and let me know what you think?
>
> I took a quick look, and while I really am convinced that our own
> framework is necessary for all sorts of reasons I and others have listed
> already, I do wonder if we could simply do better via using jetty or
> tomcat in some way?
>
> geir
>
>


--
Thanks,
Stepan Mishura
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message