commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <>
Subject [HttpClient] RE: Test suites
Date Tue, 24 Sep 2002 19:19:07 GMT
> I am curious as to how you have been approaching building tests for 
> peculiar behavior of HTTP servers.  

I don't think we have a good solution to this yet.

Right now the httpclient tests fall into three cases:

1. "pure" unit tests 

- These simply exercise the classes directly, with no external dependencies.  These are the
tests that are executed by the "test-nohost" ant target, and are bundled into a Suite under

2. webapp tests 

- These tests interact with a "known" webapp, typically running locally.  The webapp is built
using the "compile.test-webapp" target.  This webapp needs to be deployed to some app server,
and that server needs to be running in order to execute the tests.  These are the tests that
are executed by the "test-webapp" target, and are bundled into a suite under org.apache.commons.httpclient.TestAllWebapp.

3. "internet" tests

- These tests interact with various servers out on the public internet (largely these are
just the SSL tests).  You need an internet connection to execute them, and obviously the external
server needs to be up and running.  These are the tests that are executed by the "test-external"
target, and are bundled into a suite under org.apache.commons.httpclient.TestAllExternal.

The "test" target executes all three of these suites.

It should be possible to replace many of the category 2 and 3 tests with a mock server running
in process and providing canned responses (or introspecting canned requests).  This may prove
complicated in implementation, but would certainly ease the configuration/external-dependency
burdens in running the tests.  A minor refactoring that makes it easier to plug in a response
stream (or grab the request stream) in HttpConnection may simplify matters.

I'd be willing to help out a bit with that, if someone wants to get it started.  Otherwise
I think the order above is preferred (i.e., if you can't add it as a "pure" test, use the
webapp, and only if you can't easily add it to the webapp, rely upon some external server).

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message