[Python-Dev] unittest and sockets. Ugh!?

[Tim Peters]

[Michael Gilfix]
>   Could someone please offer some advice/comments on this?  While
> restructuring test_socket.py, I've come across the following
> (limitation?) problem with the unittest module. To test socket stuff,
> I really need to use two separate processes or threads.  Since
> fork() is much better supported,

Better supported than what?  Threads?  No way.  If you use fork(), the test
won't run at all except on Unixish systems.  If you use threads, it will run
just about everywhere.  Use threads.

Alas, I have no idea what unittest does in the presence of fork or threads,
and no desire to learn <wink>.

> ...
>   Any other stuff that I've seen that uses forking/threading doesn't
> seem to use the unittest style framework.

The existing fork and thread tests almost all long predate the invention of
unittest.  Frankly, I find that the layers of classes in elaborate unittests
ensure I almost always spend more time trying to understand what a failing
unittest *thinks* it's trying to do, and fixing what turn out to be bad
assumptions, than in fixing actual bugs in the stuff it's supposed to be
testing.  Combining that artificial complexity with the inherent complexity
of multiple processes or threads is something I instinctively shy away from.

My coworkers do not, and PythonLabs has done several projects now at Zope
Corp now that try to mix unittest with multiple threads and processes in the
*app* being tested.  Even that much is a never-ending nightmare.  Then
again, I feel this more acutely than them because the tests always fail on
Windows -- or any other platform where the timing is 1% different <wink>.

no-easy-answers-here-ly y'rs  - tim