[Twisted-Python] Writing unit tests with Trial for Twisted Applications

[Glyph Lefkowitz]

Jp Calderone wrote:
> Only a few of the tests you write should actually go over the
> network -- note that loopback.loopback() and the rest of the fake transport
> bit fall into this category!).  The bulk of your functionality should be
> testable in isolation of the network code.  If it's not, consider trying to
> rewrite it so it is.  This will lead to simpler, more reliable tests as well
> as simpler and more modular code.

The ideal situation in this case would be to have a briefer answer like 
"Use trial.prototest" or something.  While I appreciate the "Unit" 
aspect of unit tests (test only what you're testing) it's still good to 
actually exercise a little network code under the covers, since the OS 
can do difficult-to-replicate-and-test things in different environments.

I can't think of an easy way to do this, but there should be a 
'listenTest' utility function which can listen over TCP or SSL, or over 
a loopback connection that doesn't consume OS resources, based on a 
switch to the trial commandline.  That way we can exercise both 
interactions of the higher levels with the lower levels and the higher 
levels in effective isolation.

It occurs to me that a test reactor package would be useful for more 
than that - testReactor.run() could monitor the event loop for state 
changes - if no data is sent or received in a given iteration, then you 
know that the reactor is going to hang and you can raise a test failure 
to that effect rather than consuming CPU and hiding the traceback.

(Am I making sense here?)