Peter Hansen <[EMAIL PROTECTED]> wrote: >It seems possible to me that I might have helped him >solely by pointing out that unittest might not be so >"heavy" as some people claimed. I got the impression >that he might be swayed by some unfounded claims not >even to look further at unittest, which I felt would >be a bad thing.
I'm the "him" referred to above. I've been using unittest ever since it was first added to the standard library (actually, now that I think about it, I believe I may have been using it even before then). And yes, I think unittest brings along a certain amount of baggage. There is something attractive about having the same basic framework work in many languages (PyUnit, JUnit, C++Unit, etc), but on the other hand, it does add ballast. I use it, I certainly don't hate it, but on the other hand, there are enough things annoying about it that it's worth investing the effort to explore alternatives. >From the few days I've been playing with py.test, I think I like what I see, but it's got other issues. The "optimization elides assert" issue we've been talking about is one. It's also neat that I can write unittest-style test classes or go the simplier route of just writing static test functions, but there's a certain amount of TIMTOWTDI (did I spell that right?) smell to that. I'm also finding the very terse default output from unittest (basicly a bunch of dots followed by "all N tests passed") highly preferable to py.test's verbosity. In short, I haven't made up my mind yet, but I do appreciate the input I've gotten. -- http://mail.python.org/mailman/listinfo/python-list
