Start by virtualizing the access to the connection, and then, rather than having multiple servers, just have different implementations of a virtualized "socket" interface, for example. Then see to writing test cases that look something like this:
# This marks what the "server" is supposed to receive, note that this is not
# literally what is received, because headers might be "sent" in a different order
# for example.
>>GET /foo HTTP/1.1
@Host: http://localhost:8080
@Content-Length: 30
@End-Headers
# Note that on "content lines, the CRLF (or just LF) should be
# discarded. Instead, CRLF pairs should be explicitly encoded, perhaps
# with %CRLF%? Content should (must?) allow substitutions, for example
# multi-part boundaries. Perhaps do substitution with something like
# %BOUNDARY%
@Content:
Content goes here....
# the following would wait for three seconds before sending more
# content...
@Wait: 3000
@Content:
Yet more content here...
<<HTTP/1.1
# Note, here since the test case "knows" the response it is supposed to
# send, it can (by and large) simply send it.
@Content:
.....
and so on....
I spend a lot of time working with XML, so I thought about doing some sort of test-framework like the above using XML instead. which would get rid of some of the bizarre syntax that I suggest above, but I'm not sure whether that makes sense in the context of HttpClient.
My idea would be to take cases where we want to talk to actual servers, and replace them with "test" cases like the above, wherein we could mimick (or exactly duplicate) the odd behavior of various servers.
Hopefully this gives someone else an idea....
-Eric.
Ortwin Glu"ck wrote:
[EMAIL PROTECTED] wrote:
Oleg,
I agree, our lack of auth/proxy tests is a continuous source of problems. One of our goals for 2.1 should be an effective method for testing all of the various combinations of proxy, authentication and SSL. Ideally it would be best to make this setup as simple as possible. Do you have any thoughts about how we can best accomplish this?
Mike
The various authentication methods should be tested against servlets in the Test-Webapp. As to proxies, we must implement a couple of tiny local servers running on different ports. Like:
TCP 81: Proxy TCP 82: SSL Proxy
Those servers should be started and stopped by the test fixtures (setup / teardown). The servers must be configurable as to which authentication method they use. This will also ensure quality of the various authentication methods, as currently their test cases are somewhat minimalistic. I'd love to hack up some code for the server side this week.
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
