[Twisted-web] Separate function for relative redirects in HTTPClientFactory

[Jean-Paul Calderone]

On Thu, 5 Mar 2009 10:27:08 -0800, David Reid <dreid at dreid.org> wrote:
>On Thu, Mar 5, 2009 at 9:27 AM, Aaron DeVore <aaron.devore at gmail.com> wrote:
>
>> Last night I restarted my work on relative redirects in
>> HTTPClientFactory (Ticket #3384). What I had forgotten was how
>> insanely difficult it is to write the test cases, which would then be
>> significantly more bug prone than the code itself. The problem is that
>> for every possible input I need to add (1) A test_* function, (2) a
>> callback, (3) one or more children to the internal web server for the
>> test_* function to connect to.
>>
>> This morning I hit on another idea: Why not separate the code in
>> HTTPClientFactory that does the fix into a separate function? Then
>> there could be one test case to make sure the code in
>> HTTPClientFactory works, then a single test case that contains a
>> series of assertEquals that test the output of the function. How does
>> that sound? Should I put it outside of HTTPClientFactory or inside?
>>
>> Cheers!
>> Aaron DeVore
>>
>
>I would suggest rewriting the test cases so you don't need to use an
>internal webserver.  You really just need to be able to send blobs of data
>to the HTTP client that contain different response codes and Location
>headers.
>
>I believe there are already some tests in twisted.web.test.test_webclient
>that do this, such as:
>
>http://twistedmatrix.com/trac/browser/trunk/twisted/web/test/test_webclient.py#L172
>http://twistedmatrix.com/trac/browser/trunk/twisted/web/test/test_webclient.py#L711
>
>Plus there are numerous other examples in twisted of not relying on even the
>loopback network interface for tests.
>

This is good advice, and it largely agrees with what Aaron was proposing,
I think.  The core idea here is to only test the code you're trying to test,
not a huge heap of other stuff.  A lot of the HTTP client tests invoke a
huge swath of Twisted Web code, and needlessly so.  Finding some way to
write new tests which only exercise the very limited set of code that the
test is actually for is definitely the way to go.

Jean-Paul