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?)