> 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 org.apache.commons.httpclient.TestAllLocal.

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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to