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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4