[TIP] unittest & TDD

Laura Creighton lac at openend.se
Sun Mar 11 08:32:39 PDT 2007

In a message of Sun, 11 Mar 2007 06:47:20 MST, "Bob Ippolito" writes:
>On 3/11/07, Atul Varma <varmaa at gmail.com> 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.
>That doesn't really happen until people ask for it on python-dev
>(which may require writing a PEP). I think that nose is probably
>aligned with the stdlib unittest enough and popular enough to where it
>would be a good fit, but the eternal questions are is it mature enough
>and who is going to maintain it in the stdlib.
>Since easy_install became widespread, I stopped caring about the
>stdlib... it just doesn't seem worth the process involved in proposing
>and actualizing a stdlib change when third party installation is so
>painless and can be updated at a different release cycle than Python

I am not sure the py.test maintainers want py.test to be part of
the standard library.  It would mean losing control of when we could
make new releases.


More information about the testing-in-python mailing list