best python unit testing framwork

[Brendan Miller]

On Thu, Nov 13, 2008 at 3:54 AM, James Harris
<james.harris.1 at googlemail.com> wrote:
> On 11 Nov, 22:59, Brendan Miller <catph... at catphive.net> 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.