On Thu, Nov 13, 2008 at 3:54 AM, James Harris <[EMAIL PROTECTED]> wrote: > On 11 Nov, 22:59, Brendan Miller <[EMAIL PROTECTED]> wrote: >> What would heavy python unit testers say is the best framework? >> >> I've seen a few mentions that maybe the built in unittest framework >> isn't that great. I've heard a couple of good things about py.test and >> nose. Are there other options? Is there any kind of concensus about >> the best, or at least how they stack up to each other? > > You don't mention what you want from testing so it's hard to say which > is "best" as it depends on one's point of view. > > For example, I had a requirement to test more than just Python > programs. I wanted to test code written in any language. None of the > frameworks I found supported this so I wrote my own tester. It > interacts with programs via file streams - principally stdin, stdout > and stderr though others can be added as needed.
I was speaking to unit tests (tests of individual classes and functions in isolation of the rest of the program) and a test driven development approach. I find those to be much more useful, and good for pinpointing bugs and guiding development. In contrast regression tests tend to be slow, and are the programmatic equivalent of kicking the tires and seeing if they fall off. I've also seen regression tests lead to a "sweep the bugs under the rug mentality" where developers will code to prevent errors from crashing the regression test, e.g. by catching and swallowing all exceptions without fixing the underlying problem. It's easy to fool regression tests since what it does works at such a high level that most aspects of program correctness can't be directly checked. This is very frustrating to me because it actually leads to lower code quality. > > One nice by-product is that test code does not bloat-out the original > source which remains unchanged. That's the main reason most people don't write unit tests. It forces them to properly decouple their code so that parts can be used independently of one another. Adding such things to messy ball of mud code after the fact is an enourmous pain in the butt. Thankfully, since python is duck typed and doesn't require lots of boilerplate writing interfaces and abstract factories (since the class object itself acts as an abstract factory), writing properly decoupled code in the first place doesn't look nearly as hard as in C++ or Java. -- http://mail.python.org/mailman/listinfo/python-list