You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stepan Mishura <st...@gmail.com> on 2006/05/22 07:16:25 UTC
Re: [classlib] jetty based tests
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.
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
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Stepan Mishura <st...@gmail.com>.
Hi Andrew,
The test you've mentioned
org.apache.harmony.tests.java.net.URLConnectionTest in not in exclude list.
And it doesn't require jetty server nor mock object to pass.
I will be helpful if you can provide an example how a test case may
force jetty server to sent it chunked or broken response.
Thanks,
Stepan.
On 5/23/06, Andrew Zhang <zh...@gmail.com> wrote:
>
> Hello, all ,
>
> I perfer to embed jetty in our test code to avoid external server in some
> test cases.
>
> "I'm not against 'jetty based tests' but I'd prefer to separate such
> tests."
>
>
> Stepan, If jetty is embedded in our test case code, I think it's
> unnecessary
> still to seperate such tests, since there's no external dependency at all.
>
> Consider following test case from URLConnectionTest.java, luni module:
>
>
> /**
> * @tests java.net.URLConnection#setUseCaches(boolean)
> */
> public void test_setUseCachesZ() throws MalformedURLException, IOException
> {
> // Regression for HARMONY-71
> URLConnection u = new URLConnection(new URL("http://www.apache.org")) {
> public void connect() {
> connected = true;
> }
> };
>
> u.connect();
> try {
> u.setUseCaches(true);
> fail("Assert 0: expected an IllegalStateException");
> } catch (IllegalStateException e) {
> // expected
> }
> }
> If we revise the test case with Jetty embedded, as following code:
>
> public class JettySample extends TestCase {
>
> private HttpServer server = null;
>
> protected void setUp() throws Exception {
> server = new HttpServer();
> SocketListener listener = new SocketListener();
> listener.setPort(80);
> server.addListener(listener);
> HttpContext context = new HttpContext();
> context.setContextPath("/");
> // currently, a folder named "webapps" is put in the project root
> directory
> // We could put this folder in project "support" if we decide to embed
> jetty
> // and configure the resource base sth. like "support/resource/...".
> context.setResourceBase("webapps");
> context.addHandler(new ResourceHandler());
> server.addContext(context);
> server.start();
> }
>
> protected void tearDown() throws Exception {
> if (null != server) {
> server.stop();
> }
> }
>
> /**
> * @tests java.net.URLConnection#setUseCaches(boolean)
> */
> public void test_setUseCachesZ() throws MalformedURLException, IOException
> {
> // Regression for HARMONY-71
> URLConnection u = new URLConnection(new URL("http://localhost")) {
> public void connect() {
> connected = true;
> }
> };
> u.connect();
> try {
> u.setUseCaches(true);
> fail("Assert 0: expected an IllegalStateException");
> } catch (IllegalStateException e) {
> // expected
> }
> }
> }
>
> People could run the revised test case without any external server. And it
> costs us two jars (or.mortbay.jetty.jar, commons-logging.jar) and about
> 300ms overhead (if log info is disabled).
>
> Any suggestion or comment ?
>
> Thanks!
>
> On 5/22/06, Stepan Mishura <st...@gmail.com> 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.
> >
> > 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
> > >
> > >
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> > ------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Andrew Zhang <zh...@gmail.com>.
Hello, all ,
I perfer to embed jetty in our test code to avoid external server in some
test cases.
"I'm not against 'jetty based tests' but I'd prefer to separate such tests."
Stepan, If jetty is embedded in our test case code, I think it's unnecessary
still to seperate such tests, since there's no external dependency at all.
Consider following test case from URLConnectionTest.java, luni module:
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL("http://www.apache.org")) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail("Assert 0: expected an IllegalStateException");
} catch (IllegalStateException e) {
// expected
}
}
If we revise the test case with Jetty embedded, as following code:
public class JettySample extends TestCase {
private HttpServer server = null;
protected void setUp() throws Exception {
server = new HttpServer();
SocketListener listener = new SocketListener();
listener.setPort(80);
server.addListener(listener);
HttpContext context = new HttpContext();
context.setContextPath("/");
// currently, a folder named "webapps" is put in the project root
directory
// We could put this folder in project "support" if we decide to embed
jetty
// and configure the resource base sth. like "support/resource/...".
context.setResourceBase("webapps");
context.addHandler(new ResourceHandler());
server.addContext(context);
server.start();
}
protected void tearDown() throws Exception {
if (null != server) {
server.stop();
}
}
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL("http://localhost")) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail("Assert 0: expected an IllegalStateException");
} catch (IllegalStateException e) {
// expected
}
}
}
People could run the revised test case without any external server. And it
costs us two jars (or.mortbay.jetty.jar, commons-logging.jar) and about
300ms overhead (if log info is disabled).
Any suggestion or comment ?
Thanks!
On 5/22/06, Stepan Mishura <st...@gmail.com> 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.
>
> 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
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] jetty based tests
Posted by Paulex Yang <pa...@gmail.com>.
Stepan Mishura wrote:
> Hi George, Paulex,
>
> Thanks for your answers. As a preliminary result - your convinced me
> and I'm
> going to be volunteer to evaluate jetty integration to classlib test
> suite.
>
Great, thank you, Stepan!
> Do anybody work on integrating jetty http server to move net tests out of
> exclude list?
I'd like to try. :-)
>
> Thanks,
> Stepan.
>
> On 5/23/06, George Harley <ge...@googlemail.com> wrote:
>>
>> Stepan Mishura 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?
>>
>> Hi Stepan,
>>
>> In addition to be being start-able, stop-able and configurable from Ant
>> and XML config files, Jetty can also be embedded into the Java code of a
>> test case or test suite. Configuration, starting and stopping are all
>> possible. Eclipse users should not be disadvantaged.
>>
>>
>> >
>> > 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?
>>
>> Depends on configuration. Configure and start the server in the setup()
>> of a JUnit TesCase (and stopping the server in the teardown()) would
>> obviously be slower than doing the equivalent in a JUnit TestSetup
>> descendent. Start up is a lot less than half a second on my machine.
>>
>> Is there some performance benchmark for tests that is at risk here ?
>>
>>
>> >
>> > 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?
>>
>> Yes. You can send back any error.
>>
>>
>> >
>> > 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.
>> >
>>
>>
>> Not sure of your point here. Is there some test file footprint benchmark
>> that is at risk here ? If there is a better, faster, more lightweight
>> server that would suit our purposes then let's hear about it so that we
>> can investigate whether or not it may be used with our network tests.
>>
>> >
>> >> 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?
>>
>> Yes. The API provides options to do this. Chunks are encoded as per
>> RFC2616.
>>
>>
>> Best regards,
>> George
>>
>> >
>> > 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
>> >>
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Stepan Mishura <st...@gmail.com>.
Hi George, Paulex,
Thanks for your answers. As a preliminary result - your convinced me and I'm
going to be volunteer to evaluate jetty integration to classlib test suite.
Do anybody work on integrating jetty http server to move net tests out of
exclude list?
Thanks,
Stepan.
On 5/23/06, George Harley <ge...@googlemail.com> wrote:
>
> Stepan Mishura 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?
>
> Hi Stepan,
>
> In addition to be being start-able, stop-able and configurable from Ant
> and XML config files, Jetty can also be embedded into the Java code of a
> test case or test suite. Configuration, starting and stopping are all
> possible. Eclipse users should not be disadvantaged.
>
>
> >
> > 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?
>
> Depends on configuration. Configure and start the server in the setup()
> of a JUnit TesCase (and stopping the server in the teardown()) would
> obviously be slower than doing the equivalent in a JUnit TestSetup
> descendent. Start up is a lot less than half a second on my machine.
>
> Is there some performance benchmark for tests that is at risk here ?
>
>
> >
> > 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?
>
> Yes. You can send back any error.
>
>
> >
> > 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.
> >
>
>
> Not sure of your point here. Is there some test file footprint benchmark
> that is at risk here ? If there is a better, faster, more lightweight
> server that would suit our purposes then let's hear about it so that we
> can investigate whether or not it may be used with our network tests.
>
> >
> >> 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?
>
> Yes. The API provides options to do this. Chunks are encoded as per
> RFC2616.
>
>
> Best regards,
> George
>
> >
> > 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
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Geir Magnusson Jr <ge...@pobox.com>.
George Harley wrote:
> Stepan Mishura 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?
>
> Hi Stepan,
>
> In addition to be being start-able, stop-able and configurable from Ant
> and XML config files, Jetty can also be embedded into the Java code of a
> test case or test suite. Configuration, starting and stopping are all
> possible. Eclipse users should not be disadvantaged.
Who cares? We have to make our test suite independent of someones
favorite IDE...
geir
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by George Harley <ge...@googlemail.com>.
Stepan Mishura 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?
Hi Stepan,
In addition to be being start-able, stop-able and configurable from Ant
and XML config files, Jetty can also be embedded into the Java code of a
test case or test suite. Configuration, starting and stopping are all
possible. Eclipse users should not be disadvantaged.
>
> 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?
Depends on configuration. Configure and start the server in the setup()
of a JUnit TesCase (and stopping the server in the teardown()) would
obviously be slower than doing the equivalent in a JUnit TestSetup
descendent. Start up is a lot less than half a second on my machine.
Is there some performance benchmark for tests that is at risk here ?
>
> 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?
Yes. You can send back any error.
>
> 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.
>
Not sure of your point here. Is there some test file footprint benchmark
that is at risk here ? If there is a better, faster, more lightweight
server that would suit our purposes then let's hear about it so that we
can investigate whether or not it may be used with our network tests.
>
>> 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?
Yes. The API provides options to do this. Chunks are encoded as per
RFC2616.
Best regards,
George
>
> 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
>>
>>
>
>
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by George Harley <ge...@googlemail.com>.
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.
>
> 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.
>
Hi Andrew,
What are the negative tests and special tests that Jetty could not satisfy ?
Best regards,
George
> What's your opnion?
>
> Thanks.
>
>
> On 5/23/06, Stepan Mishura <st...@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
>> >
>> >
>>
>>
>> --
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>> ------------------------------------------------------
>> 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
Re: [classlib] jetty based tests
Posted by George Harley <ge...@googlemail.com>.
Paulex Yang wrote:
> Mikhail Loenko wrote:
>> Can jetty send back for example a response consisting of the
>> following 4 bytes:
>>
>> 0x00 0x01 0x02 0x03
> Sure, but if you need control of such level, a mocked SocketListener
> may be necessary, check out the codes below, the client socket will
> print 0-3, respectively.
>
> public class JettyTest {
> public static void main(String[] args) throws Exception {
> HttpServer server = new HttpServer();
> SocketListener listener = new MockSocketListener();
> listener.setPort(80);
> server.addListener(listener);
> server.start();
> Socket socket = new Socket(InetAddress.getByName("localhost"),
> 80);
> InputStream is = socket.getInputStream();
> int c;
> while ((c = is.read()) != -1) {
> System.out.println(c);
> }
> socket.close();
> server.stop();
> }
> }
>
> class MockSocketListener extends SocketListener {
> public void handleConnection(Socket socket) throws IOException {
> OutputStream os = socket.getOutputStream();
> os.write(new byte[]{0x00, 0x01, 0x02, 0x03});
> socket.close();
> }
> }
>
> I'm sure Jetty has more potential, I'm a newbie of Jetty myself :-)
We all are.
Best regards,
George
>>
>> ?
>>
>> Thanks,
>> Mikhail
>>
>> 2006/5/23, Paulex Yang <pa...@gmail.com>:
>>> Stepan Mishura 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).
>>> But we still need to implement http protocol sometimes. That's what we
>>> can leverage from current product such as Jetty.
>>> > 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?
>>> >
>>> If I understand correctly, the positive tests needs understand the http
>>> protocol, doesn't it?
>>>
>>> BTW, I just checked the Jetty's JavaDoc quickly, and found that the
>>> HttpContext can set customized ResourceHandlers, so that I can see some
>>> possibility to provide negative test by Jetty easily. For example, we
>>> can define a standard negative test context as path "/mockerror", and
>>> set a MockErrorResourceHandler for this context, which outputs negative
>>> result to client, and the mocked ResourceHandler should only need to
>>> override handle() method.
>>>
>>> > Thanks,
>>> > Stepan.
>>> >
>>> > What's your opnion?
>>> >>
>>> >> Thanks.
>>> >>
>>> >>
>>> >> On 5/23/06, Stepan Mishura <st...@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
>>> >> > >
>>> >> > >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Thanks,
>>> >> > Stepan Mishura
>>> >> > Intel Middleware Products Division
>>> >> >
>>> >> > ------------------------------------------------------
>>> >> > 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
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Andrew Zhang
>>> >> China Software Development Lab, IBM
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>> --
>>> Paulex Yang
>>> China Software Development Lab
>>> IBM
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Paulex Yang <pa...@gmail.com>.
Mikhail Loenko wrote:
> Can jetty send back for example a response consisting of the following
> 4 bytes:
>
> 0x00 0x01 0x02 0x03
Sure, but if you need control of such level, a mocked SocketListener
may be necessary, check out the codes below, the client socket will
print 0-3, respectively.
public class JettyTest {
public static void main(String[] args) throws Exception {
HttpServer server = new HttpServer();
SocketListener listener = new MockSocketListener();
listener.setPort(80);
server.addListener(listener);
server.start();
Socket socket = new Socket(InetAddress.getByName("localhost"), 80);
InputStream is = socket.getInputStream();
int c;
while ((c = is.read()) != -1) {
System.out.println(c);
}
socket.close();
server.stop();
}
}
class MockSocketListener extends SocketListener {
public void handleConnection(Socket socket) throws IOException {
OutputStream os = socket.getOutputStream();
os.write(new byte[]{0x00, 0x01, 0x02, 0x03});
socket.close();
}
}
I'm sure Jetty has more potential, I'm a newbie of Jetty myself :-)
>
> ?
>
> Thanks,
> Mikhail
>
> 2006/5/23, Paulex Yang <pa...@gmail.com>:
>> Stepan Mishura 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).
>> But we still need to implement http protocol sometimes. That's what we
>> can leverage from current product such as Jetty.
>> > 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?
>> >
>> If I understand correctly, the positive tests needs understand the http
>> protocol, doesn't it?
>>
>> BTW, I just checked the Jetty's JavaDoc quickly, and found that the
>> HttpContext can set customized ResourceHandlers, so that I can see some
>> possibility to provide negative test by Jetty easily. For example, we
>> can define a standard negative test context as path "/mockerror", and
>> set a MockErrorResourceHandler for this context, which outputs negative
>> result to client, and the mocked ResourceHandler should only need to
>> override handle() method.
>>
>> > Thanks,
>> > Stepan.
>> >
>> > What's your opnion?
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> On 5/23/06, Stepan Mishura <st...@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
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Thanks,
>> >> > Stepan Mishura
>> >> > Intel Middleware Products Division
>> >> >
>> >> > ------------------------------------------------------
>> >> > 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
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Andrew Zhang
>> >> China Software Development Lab, IBM
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Paulex Yang <pa...@gmail.com>.
George Harley wrote:
> Mikhail Loenko wrote:
>> 2006/5/23, George Harley <ge...@googlemail.com>:
>>> Mikhail Loenko wrote:
>>> > Can jetty send back for example a response consisting of the
>>> following
>>> > 4 bytes:
>>> >
>>> > 0x00 0x01 0x02 0x03
>>> >
>>> > ?
>>>
>>> Have you checked ?
>>
>> I'm just asking. I do not state that
>>
>>
>
> Hi Mikhail,
>
> I misunderstood your append - thought that it was a statement rather
> than a question. The "?" should have tipped me off though :-)
>
> Yes, I believe that it can. I used the following handler to do the job
> ...
>
> class BytesHandler extends AbstractHttpHandler {
>
> public void handle(String pathInConext, String pathParams,
> HttpRequest request, HttpResponse response)
> throws HttpException, IOException {
> OutputStream os = response.getOutputStream();
> byte[] bytes = new byte[]{0x00, 0x01, 0x02, 0x03};
> os.write(bytes, 0, 4);
> os.flush();
> request.setHandled(true);
> }
> }
Ah, good catch! this way seems better than mine, the HttpHandler only
works for some HttpContext.
>
>
> Best regards,
> George
>
>
>
>>>
>>> Best regards,
>>> George
>>>
>>>
>>> >
>>> > Thanks,
>>> > Mikhail
>>> >
>>> > 2006/5/23, Paulex Yang <pa...@gmail.com>:
>>> >> Stepan Mishura 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).
>>> >> But we still need to implement http protocol sometimes. That's
>>> what we
>>> >> can leverage from current product such as Jetty.
>>> >> > 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?
>>> >> >
>>> >> If I understand correctly, the positive tests needs understand
>>> the http
>>> >> protocol, doesn't it?
>>> >>
>>> >> BTW, I just checked the Jetty's JavaDoc quickly, and found that the
>>> >> HttpContext can set customized ResourceHandlers, so that I can
>>> see some
>>> >> possibility to provide negative test by Jetty easily. For
>>> example, we
>>> >> can define a standard negative test context as path "/mockerror",
>>> and
>>> >> set a MockErrorResourceHandler for this context, which outputs
>>> negative
>>> >> result to client, and the mocked ResourceHandler should only need to
>>> >> override handle() method.
>>> >>
>>> >> > Thanks,
>>> >> > Stepan.
>>> >> >
>>> >> > What's your opnion?
>>> >> >>
>>> >> >> Thanks.
>>> >> >>
>>> >> >>
>>> >> >> On 5/23/06, Stepan Mishura <st...@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
>>> >> >> > >
>>> >> >> > >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Thanks,
>>> >> >> > Stepan Mishura
>>> >> >> > Intel Middleware Products Division
>>> >> >> >
>>> >> >> > ------------------------------------------------------
>>> >> >> > 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
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Andrew Zhang
>>> >> >> China Software Development Lab, IBM
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Paulex Yang
>>> >> China Software Development Lab
>>> >> IBM
>>> >>
>>> >>
>>> >>
>>> >>
>>> ---------------------------------------------------------------------
>>> >> 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
>>> >
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by George Harley <ge...@googlemail.com>.
Mikhail Loenko wrote:
> 2006/5/23, George Harley <ge...@googlemail.com>:
>> Mikhail Loenko wrote:
>> > Can jetty send back for example a response consisting of the following
>> > 4 bytes:
>> >
>> > 0x00 0x01 0x02 0x03
>> >
>> > ?
>>
>> Have you checked ?
>
> I'm just asking. I do not state that
>
>
Hi Mikhail,
I misunderstood your append - thought that it was a statement rather
than a question. The "?" should have tipped me off though :-)
Yes, I believe that it can. I used the following handler to do the job ...
class BytesHandler extends AbstractHttpHandler {
public void handle(String pathInConext, String pathParams,
HttpRequest request, HttpResponse response)
throws HttpException, IOException {
OutputStream os = response.getOutputStream();
byte[] bytes = new byte[]{0x00, 0x01, 0x02, 0x03};
os.write(bytes, 0, 4);
os.flush();
request.setHandled(true);
}
}
Best regards,
George
>>
>> Best regards,
>> George
>>
>>
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/5/23, Paulex Yang <pa...@gmail.com>:
>> >> Stepan Mishura 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).
>> >> But we still need to implement http protocol sometimes. That's
>> what we
>> >> can leverage from current product such as Jetty.
>> >> > 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?
>> >> >
>> >> If I understand correctly, the positive tests needs understand the
>> http
>> >> protocol, doesn't it?
>> >>
>> >> BTW, I just checked the Jetty's JavaDoc quickly, and found that the
>> >> HttpContext can set customized ResourceHandlers, so that I can see
>> some
>> >> possibility to provide negative test by Jetty easily. For example, we
>> >> can define a standard negative test context as path "/mockerror", and
>> >> set a MockErrorResourceHandler for this context, which outputs
>> negative
>> >> result to client, and the mocked ResourceHandler should only need to
>> >> override handle() method.
>> >>
>> >> > Thanks,
>> >> > Stepan.
>> >> >
>> >> > What's your opnion?
>> >> >>
>> >> >> Thanks.
>> >> >>
>> >> >>
>> >> >> On 5/23/06, Stepan Mishura <st...@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
>> >> >> > >
>> >> >> > >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Thanks,
>> >> >> > Stepan Mishura
>> >> >> > Intel Middleware Products Division
>> >> >> >
>> >> >> > ------------------------------------------------------
>> >> >> > 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
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Andrew Zhang
>> >> >> China Software Development Lab, IBM
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Paulex Yang
>> >> China Software Development Lab
>> >> IBM
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/5/23, George Harley <ge...@googlemail.com>:
> Mikhail Loenko wrote:
> > Can jetty send back for example a response consisting of the following
> > 4 bytes:
> >
> > 0x00 0x01 0x02 0x03
> >
> > ?
>
> Have you checked ?
I'm just asking. I do not state that
>
> Best regards,
> George
>
>
> >
> > Thanks,
> > Mikhail
> >
> > 2006/5/23, Paulex Yang <pa...@gmail.com>:
> >> Stepan Mishura 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).
> >> But we still need to implement http protocol sometimes. That's what we
> >> can leverage from current product such as Jetty.
> >> > 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?
> >> >
> >> If I understand correctly, the positive tests needs understand the http
> >> protocol, doesn't it?
> >>
> >> BTW, I just checked the Jetty's JavaDoc quickly, and found that the
> >> HttpContext can set customized ResourceHandlers, so that I can see some
> >> possibility to provide negative test by Jetty easily. For example, we
> >> can define a standard negative test context as path "/mockerror", and
> >> set a MockErrorResourceHandler for this context, which outputs negative
> >> result to client, and the mocked ResourceHandler should only need to
> >> override handle() method.
> >>
> >> > Thanks,
> >> > Stepan.
> >> >
> >> > What's your opnion?
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> >> >> On 5/23/06, Stepan Mishura <st...@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
> >> >> > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Thanks,
> >> >> > Stepan Mishura
> >> >> > Intel Middleware Products Division
> >> >> >
> >> >> > ------------------------------------------------------
> >> >> > 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
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Andrew Zhang
> >> >> China Software Development Lab, IBM
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [classlib] jetty based tests
Posted by George Harley <ge...@googlemail.com>.
Mikhail Loenko wrote:
> Can jetty send back for example a response consisting of the following
> 4 bytes:
>
> 0x00 0x01 0x02 0x03
>
> ?
Have you checked ?
Best regards,
George
>
> Thanks,
> Mikhail
>
> 2006/5/23, Paulex Yang <pa...@gmail.com>:
>> Stepan Mishura 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).
>> But we still need to implement http protocol sometimes. That's what we
>> can leverage from current product such as Jetty.
>> > 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?
>> >
>> If I understand correctly, the positive tests needs understand the http
>> protocol, doesn't it?
>>
>> BTW, I just checked the Jetty's JavaDoc quickly, and found that the
>> HttpContext can set customized ResourceHandlers, so that I can see some
>> possibility to provide negative test by Jetty easily. For example, we
>> can define a standard negative test context as path "/mockerror", and
>> set a MockErrorResourceHandler for this context, which outputs negative
>> result to client, and the mocked ResourceHandler should only need to
>> override handle() method.
>>
>> > Thanks,
>> > Stepan.
>> >
>> > What's your opnion?
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> On 5/23/06, Stepan Mishura <st...@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
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Thanks,
>> >> > Stepan Mishura
>> >> > Intel Middleware Products Division
>> >> >
>> >> > ------------------------------------------------------
>> >> > 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
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Andrew Zhang
>> >> China Software Development Lab, IBM
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Mikhail Loenko <ml...@gmail.com>.
Can jetty send back for example a response consisting of the following 4 bytes:
0x00 0x01 0x02 0x03
?
Thanks,
Mikhail
2006/5/23, Paulex Yang <pa...@gmail.com>:
> Stepan Mishura 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).
> But we still need to implement http protocol sometimes. That's what we
> can leverage from current product such as Jetty.
> > 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?
> >
> If I understand correctly, the positive tests needs understand the http
> protocol, doesn't it?
>
> BTW, I just checked the Jetty's JavaDoc quickly, and found that the
> HttpContext can set customized ResourceHandlers, so that I can see some
> possibility to provide negative test by Jetty easily. For example, we
> can define a standard negative test context as path "/mockerror", and
> set a MockErrorResourceHandler for this context, which outputs negative
> result to client, and the mocked ResourceHandler should only need to
> override handle() method.
>
> > Thanks,
> > Stepan.
> >
> > What's your opnion?
> >>
> >> Thanks.
> >>
> >>
> >> On 5/23/06, Stepan Mishura <st...@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
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Thanks,
> >> > Stepan Mishura
> >> > Intel Middleware Products Division
> >> >
> >> > ------------------------------------------------------
> >> > 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
> >> >
> >> >
> >>
> >>
> >> --
> >> Andrew Zhang
> >> China Software Development Lab, IBM
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [classlib] jetty based tests
Posted by Paulex Yang <pa...@gmail.com>.
Stepan Mishura 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).
But we still need to implement http protocol sometimes. That's what we
can leverage from current product such as Jetty.
> 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?
>
If I understand correctly, the positive tests needs understand the http
protocol, doesn't it?
BTW, I just checked the Jetty's JavaDoc quickly, and found that the
HttpContext can set customized ResourceHandlers, so that I can see some
possibility to provide negative test by Jetty easily. For example, we
can define a standard negative test context as path "/mockerror", and
set a MockErrorResourceHandler for this context, which outputs negative
result to client, and the mocked ResourceHandler should only need to
override handle() method.
> Thanks,
> Stepan.
>
> What's your opnion?
>>
>> Thanks.
>>
>>
>> On 5/23/06, Stepan Mishura <st...@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
>> > >
>> > >
>> >
>> >
>> > --
>> > Thanks,
>> > Stepan Mishura
>> > Intel Middleware Products Division
>> >
>> > ------------------------------------------------------
>> > 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
>> >
>> >
>>
>>
>> --
>> Andrew Zhang
>> China Software Development Lab, IBM
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> This thread was a long read :)
>>
>> 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...
Exactly... I assumed that it was just a property in .properties file
rather than a separate config, but we'll see what the impl comes up
with, I suppose.
geir
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Anton Luht <an...@gmail.com>.
Good day,
> > The only problem with local server is choosing a local port to bind to
> > - port 80 is often used by another daemon. Test should try to start
> > Jetty on a free port and tell its number to the URLConnection test.
>
> Autonomically? I don't think so - I think it should be a configuration
> parameter set by the tester so things are repeatable....
I don't insist on auto-picking the port - I just wanted to draw
attention to busy ports problem. Configuration parameter is fine, too.
> > My opinion is that remote server should not be used in tests - it's
> > problematic and doesn't give any advantages.
> >
>
> It's a choice here. I agree it should not be *required*, and that by
> default, one should be able to run the test suite on an airplane when
> the airline isn't Lufthansa :)
Sure - if there's a test that connects to a remote server, it's better
to put it as a bonus rather than to throw it away :)
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Andrew Zhang <zh...@gmail.com>.
On 5/25/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
> Yang Paulex wrote:
> > +1 from me
> >
> > I also suggest we use Jetty as a singleton, so that we don't need to
> pay
> > the overhead to find an available port and to start http server.
>
> Doesn't the above "don't need to pay the overhead to find an available
> port" conflict with the element #1 below, "lazily start Jetty when
> necessary on an available port"
I don't think "singleton" conflicts with "lazily start".
Jetty server starts only once and starts up when there's some case needs it.
:)
Sorry - I'm just confused.
>
> (I think that the port should be pre defined (well-known) have a default
> value, and be overridable in a properties/-ish file.
What's the problem if the port is selected automatically?
If I understand correctly, it means Jetty selects a free port from system,
and provides an API method (e.g. getJettyPort()) to get the selected port.
In this way, listen port confliction issue could be completely avoided.
geir
>
> >
> > The proposal is:
> > 1. Some utility class in support project is responsible to lazily start
> > Jetty when necessary on an available port in embedded mode, and to stop
> it
> > when all test cases exit
> > 2. every test class using Jetty is responsible to maintain its own
> context
> > named as "/<module name>/<package name>" and corresponding handler
> >
> > ideas and comments?
> >
> >
> > 2006/5/25, Anton Luht <an...@gmail.com>:
> >>
> >> Good day,
> >>
> >> > 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...
> >>
> >> It seems to me that remote server is not requires in HTTP tests. The
> >> only difference between local HTTP server and the remote one is that
> >> the first is reached via loopback and the latter - via "real" net.
> >> Testing of network connections is out of scope of HTTP functionality
> >> tests so local server shoud be enough.
> >>
> >> Remote server has obvious drawbacks:
> >> - if we compare in tests data fetched by via HTTP to some expected
> >> result, it's likely that contents of remote site (say, apache.org)
> >> will change and tests will fail
> >> - some companies and providers don't allow to connect from internal
> >> network to the Internet directly - 'telnet ... 80' will fail. The
> >> direct connection functionality cannot be tested in this environment.
> >>
> >> Remote server is not required even for proxy tests - Jetty can be
> >> configured to run as proxy server.
> >>
> >> The only problem with local server is choosing a local port to bind to
> >> - port 80 is often used by another daemon. Test should try to start
> >> Jetty on a free port and tell its number to the URLConnection test.
> >>
> >> My opinion is that remote server should not be used in tests - it's
> >> problematic and doesn't give any advantages.
> >>
> >> --
> >> Regards,
> >> Anton Luht,
> >> Intel Middleware Products Division
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] jetty based tests
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Yang Paulex wrote:
> +1 from me
>
> I also suggest we use Jetty as a singleton, so that we don't need to pay
> the overhead to find an available port and to start http server.
Doesn't the above "don't need to pay the overhead to find an available
port" conflict with the element #1 below, "lazily start Jetty when
necessary on an available port"
Sorry - I'm just confused.
(I think that the port should be pre defined (well-known) have a default
value, and be overridable in a properties/-ish file.
geir
>
> The proposal is:
> 1. Some utility class in support project is responsible to lazily start
> Jetty when necessary on an available port in embedded mode, and to stop it
> when all test cases exit
> 2. every test class using Jetty is responsible to maintain its own context
> named as "/<module name>/<package name>" and corresponding handler
>
> ideas and comments?
>
>
> 2006/5/25, Anton Luht <an...@gmail.com>:
>>
>> Good day,
>>
>> > 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...
>>
>> It seems to me that remote server is not requires in HTTP tests. The
>> only difference between local HTTP server and the remote one is that
>> the first is reached via loopback and the latter - via "real" net.
>> Testing of network connections is out of scope of HTTP functionality
>> tests so local server shoud be enough.
>>
>> Remote server has obvious drawbacks:
>> - if we compare in tests data fetched by via HTTP to some expected
>> result, it's likely that contents of remote site (say, apache.org)
>> will change and tests will fail
>> - some companies and providers don't allow to connect from internal
>> network to the Internet directly - 'telnet ... 80' will fail. The
>> direct connection functionality cannot be tested in this environment.
>>
>> Remote server is not required even for proxy tests - Jetty can be
>> configured to run as proxy server.
>>
>> The only problem with local server is choosing a local port to bind to
>> - port 80 is often used by another daemon. Test should try to start
>> Jetty on a free port and tell its number to the URLConnection test.
>>
>> My opinion is that remote server should not be used in tests - it's
>> problematic and doesn't give any advantages.
>>
>> --
>> Regards,
>> Anton Luht,
>> Intel Middleware Products Division
>>
>> ---------------------------------------------------------------------
>> 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
Re: [classlib] jetty based tests
Posted by Yang Paulex <pa...@gmail.com>.
+1 from me
I also suggest we use Jetty as a singleton, so that we don't need to pay
the overhead to find an available port and to start http server.
The proposal is:
1. Some utility class in support project is responsible to lazily start
Jetty when necessary on an available port in embedded mode, and to stop it
when all test cases exit
2. every test class using Jetty is responsible to maintain its own context
named as "/<module name>/<package name>" and corresponding handler
ideas and comments?
2006/5/25, Anton Luht <an...@gmail.com>:
>
> Good day,
>
> > 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...
>
> It seems to me that remote server is not requires in HTTP tests. The
> only difference between local HTTP server and the remote one is that
> the first is reached via loopback and the latter - via "real" net.
> Testing of network connections is out of scope of HTTP functionality
> tests so local server shoud be enough.
>
> Remote server has obvious drawbacks:
> - if we compare in tests data fetched by via HTTP to some expected
> result, it's likely that contents of remote site (say, apache.org)
> will change and tests will fail
> - some companies and providers don't allow to connect from internal
> network to the Internet directly - 'telnet ... 80' will fail. The
> direct connection functionality cannot be tested in this environment.
>
> Remote server is not required even for proxy tests - Jetty can be
> configured to run as proxy server.
>
> The only problem with local server is choosing a local port to bind to
> - port 80 is often used by another daemon. Test should try to start
> Jetty on a free port and tell its number to the URLConnection test.
>
> My opinion is that remote server should not be used in tests - it's
> problematic and doesn't give any advantages.
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> 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
>
>
--
Paulex Yang
China Software Development Labotary
IBM
Re: [classlib] jetty based tests
Posted by Tim Ellison <t....@gmail.com>.
I don't feel strongly about it -- I was simply responding to Geir's
request that we have an option to test against a remote server. I think
we can have that option if people want to.
Regards,
Tim
Anton Luht wrote:
> Good day,
>
>> 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...
>
> It seems to me that remote server is not requires in HTTP tests. The
> only difference between local HTTP server and the remote one is that
> the first is reached via loopback and the latter - via "real" net.
> Testing of network connections is out of scope of HTTP functionality
> tests so local server shoud be enough.
>
> Remote server has obvious drawbacks:
> - if we compare in tests data fetched by via HTTP to some expected
> result, it's likely that contents of remote site (say, apache.org)
> will change and tests will fail
> - some companies and providers don't allow to connect from internal
> network to the Internet directly - 'telnet ... 80' will fail. The
> direct connection functionality cannot be tested in this environment.
>
> Remote server is not required even for proxy tests - Jetty can be
> configured to run as proxy server.
>
> The only problem with local server is choosing a local port to bind to
> - port 80 is often used by another daemon. Test should try to start
> Jetty on a free port and tell its number to the URLConnection test.
>
> My opinion is that remote server should not be used in tests - it's
> problematic and doesn't give any advantages.
>
--
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
Re: [classlib] jetty based tests
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Anton Luht wrote:
> Good day,
>
>> 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...
>
> It seems to me that remote server is not requires in HTTP tests. The
> only difference between local HTTP server and the remote one is that
> the first is reached via loopback and the latter - via "real" net.
> Testing of network connections is out of scope of HTTP functionality
> tests so local server shoud be enough.
How do you "pull the wire"? I think that having that option for testing
things would be nice.
>
> Remote server has obvious drawbacks:
> - if we compare in tests data fetched by via HTTP to some expected
> result, it's likely that contents of remote site (say, apache.org)
> will change and tests will fail
> - some companies and providers don't allow to connect from internal
> network to the Internet directly - 'telnet ... 80' will fail. The
> direct connection functionality cannot be tested in this environment.
>
> Remote server is not required even for proxy tests - Jetty can be
> configured to run as proxy server.
>
> The only problem with local server is choosing a local port to bind to
> - port 80 is often used by another daemon. Test should try to start
> Jetty on a free port and tell its number to the URLConnection test.
Autonomically? I don't think so - I think it should be a configuration
parameter set by the tester so things are repeatable....
>
> My opinion is that remote server should not be used in tests - it's
> problematic and doesn't give any advantages.
>
It's a choice here. I agree it should not be *required*, and that by
default, one should be able to run the test suite on an airplane when
the airline isn't Lufthansa :)
geir
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Anton Luht <an...@gmail.com>.
Good day,
> 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...
It seems to me that remote server is not requires in HTTP tests. The
only difference between local HTTP server and the remote one is that
the first is reached via loopback and the latter - via "real" net.
Testing of network connections is out of scope of HTTP functionality
tests so local server shoud be enough.
Remote server has obvious drawbacks:
- if we compare in tests data fetched by via HTTP to some expected
result, it's likely that contents of remote site (say, apache.org)
will change and tests will fail
- some companies and providers don't allow to connect from internal
network to the Internet directly - 'telnet ... 80' will fail. The
direct connection functionality cannot be tested in this environment.
Remote server is not required even for proxy tests - Jetty can be
configured to run as proxy server.
The only problem with local server is choosing a local port to bind to
- port 80 is often used by another daemon. Test should try to start
Jetty on a free port and tell its number to the URLConnection test.
My opinion is that remote server should not be used in tests - it's
problematic and doesn't give any advantages.
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Tim Ellison <t....@gmail.com>.
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 <zh...@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 <st...@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 <st...@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
>
>
--
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
Re: [classlib] jetty based tests
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
> 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.)
>
+1. There are so many net-related tests laying in the exclude-list,
Jetty really helps.
> 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 <zh...@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 <st...@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 <st...@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
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 <zh...@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 <st...@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 <st...@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
Re: [classlib] jetty based tests
Posted by Stepan Mishura <st...@gmail.com>.
On 5/23/06, Andrew Zhang <zh...@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 <st...@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 <st...@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
Re: [classlib] jetty based tests
Posted by Andrew Zhang <zh...@gmail.com>.
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.
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?
Thanks.
On 5/23/06, Stepan Mishura <st...@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 <st...@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
> > > >
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > Stepan Mishura
> > > Intel Middleware Products Division
> > >
> > > ------------------------------------------------------
> > > 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
> > >
> > >
> >
> >
> > --
> > Andrew Zhang
> > China Software Development Lab, IBM
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] jetty based tests
Posted by Stepan Mishura <st...@gmail.com>.
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 <st...@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
> > >
> > >
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> > ------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by Andrew Zhang <zh...@gmail.com>.
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.
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.
What's your opnion?
Thanks.
On 5/23/06, Stepan Mishura <st...@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
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] jetty based tests
Posted by Stepan Mishura <st...@gmail.com>.
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
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib] jetty based tests
Posted by George Harley <ge...@googlemail.com>.
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, 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. 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).
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>
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
Re: [classlib] jetty based tests
Posted by Tim Ellison <t....@gmail.com>.
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.
AIUI the plan is to embed Jetty into the harmony test suite, not call it
out as a dependency we expect people to configure.
This is in contrast to, say, tests for the DNS provider that we will
likely want to use mocks objects to test rather than embed/require an
external DNS server.
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