[Twisted-Python] the right way of unit testing protocols

[Andrew Bennetts]

On Thu, Jul 31, 2003 at 10:43:55PM +0300, Tommi Virtanen wrote:
> On Thu, Jul 31, 2003 at 11:03:07AM -0400, Itamar Shtull-Trauring wrote:
> > > 	Opening TCP sockets in unit tests is just not _unit_ testing
> > > 	in my book. Please don't do it in unit tests. It just makes it
> > > 	harder to run your unit tests in varying environments. (Who
> > > 	says I allow you to bind to port 1234? Who says it's free?
> > > 	Who says I allow you to listen *at all*?)
> > 
> > Most of Twisted's unittests listen on 0 and then figure out which port
> > was bound to. 
> 
> 	Which is mostly the reason why I'm bitch about it on _this_
> 	mailing list.
> 
> 	I dislike that method. I really do.
> 
> 	There have been _months_ during which certain twisted unit
> 	tests randomly fail; many of those have been due to
> 	interaction with local TCP stack, networking, firewall and
> 	miscellanous experimental security features.

I've *never* seen a failure due to listening on 0, either on my own
machines, or on the buildslaves, or reports on this list or IRC.  I'd be
inclined to agree with you if there was actually some evidence of a problem.

I *have* seen failures due to assuming that a *particular* port is
available, and that's definitely a no-no, because it could legitimately be
in use (especially if someone else is running tests on the same machine! :).
That's why none of the Twisted unit tests do this anymore.  Listening on 0
(as our TCP tests do, and as twisted.protocols.loopback.loopbackTCP does)
asks the OS to use any available port it likes, and I've never seen it fail.

-Andrew.