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

[Michael Gilfix]

On Sat, Jun 08 @ 21:00, Tim Peters wrote:
> 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.

  Will do. I would have much rather used threads to begin with in fact.
I just assumed that the reason the socket module used fork to begin with is
because it was considered more portable. Well, you know that thing about
assuming makes an ass-out-of-u-and-me.

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

  I'll just change it to threads happily and find out :)

> > ...
> >   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.

  I would agree in some respects. When I first started looking
at unittest, I thought it seemed more complicated than it was
worth. Indeed, I'm sure the advanced features are. I don't find the
documentation to be very good at describing just what I needed to get
going - at least not up to par with, for example, the xml.minidom
documentation, which gets you going in 5 minutes.  I just haven't
made up my mind yet about what's bugging me and maybe I'll have more
insight after the process.

  However, after trying it a bit, I've decided that I really like the
format/layout and it's quite convient. I'm just not sure what it can
and can't do yet.

> 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>.

  Well, it's easier to envision with sockets where the timing issues
are easier to sort out. But well written tests are a blessing and the
more I look at the python regression suite, I begin to realize that
they are lacking <grin>.

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

  agreeingly-and-I-hope-I-don't-pick-up-this-habit-ly y'rs

                         -- Mike

-- 
Michael Gilfix
mgilfix@eecs.tufts.edu

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html