[TIP] unittest & TDD

jason pellerin jpellerin at gmail.com
Sun Mar 11 19:32:07 PDT 2007

On 3/11/07, Titus Brown <titus at caltech.edu> wrote:
> On Sun, Mar 11, 2007 at 08:35:32AM -0500, Atul Varma wrote:
> -> On 3/4/07, Bob Ippolito <bob at redivi.com> wrote:
> -> >I agree that unittest is straightforward, but it's annoying (on its
> -> >own). Too much unnecessary cruft.
> ->
> -> I agree.  Out of curiosity, is there any movement towards making
> -> py.test or nose a part of Python's standard library?  The main reason
> -> my company used unittest is, quite honestly, because we didn't look at
> -> any other testing options when we started writing our unit tests,
> -> assuming that the testing framework that shipped with Python was just
> -> "the one way to do it" (a la Python's motto).  We weren't huge fans of
> -> its complexity (or rather, the boilerplate cruft caused by said
> -> complexity), but we dealt with it.  The fact that unittest was pretty
> -> well documented helped a lot, too, but as soon as I saw py.test I had
> -> wished I'd known about it before I started writing unit tests.
> hi, Atul,
> IMO this is partly a "release schedule" problem and partly a community
> problem.
> First, I don't get the impression that either nose or py.test are at a
> stable resting point.  I could be wrong.

That's certainly true of nose. It's nowhere near a stdlib level of
stability. Plus, I hope the new unittest in py3k is going to be much
different (and much better IMO)*, so I think the right time to talk
about integrating new test loading or running into stdlib will be more
like a couple of years from now.

* In case anyone hasn't seen it, Collin Winter's draft design for
unittest in 3k is well worth checking out:
http://oakwinter.com/code/a-new-unittest/. I think it will really help
to untangle the various concerns of test loading, running and


More information about the testing-in-python mailing list