[TIP] unittest & TDD

[Collin Winter]

On 3/12/07, Titus Brown <titus at caltech.edu> wrote:
> -> Py3k is a chance to fix long-standing design mistakes, and I consider
> -> unittest's core design a mistake from start to finish. This effort
> -> started off with an intention merely to tweak and prod the existing
> -> unittest, an attempt to make it easier to compose a number of the
> -> unittest extensions I'd written over the years. #1 on my personal list
> -> of grudges was "inability to compose extensions without massive
> -> rewrites". To that end, I poked, tweaked, prodded and twisted the
> -> original design until I was left with something that resembled the old
> -> unittest in name only. This didn't start out as a rewrite -- it just
> -> ended up that way.
>
> ;)
>
> -> That said, I'm working on a backwards compatibility layer that should
> -> allow most existing unittest-based test suites to work without
> -> additional modifications. This portion is still in its infancy, but
> -> it's a high priority.
>
> nose is extensible, runs unittest tests, supports 'setup.py test', and
> is used by a number of people.
>
> py.test fits all of the above criteria too.
>
> So, do we need a third? ;)
>
> From your reply to my earlier e-mail:
>
> -> py.test and nose might be great, but the only way I'd know about them
> -> is if I went searching for them, something most people won't do unless
> -> they hit some serious problem in their day-to-day encounters with
> -> unittest.
>
> This is true.  So, perhaps we should propose that either nose or py.test
> get dropped into Py3K, instead of a new unittest module?  Obviously I'd
> personally like nose, but I'd prefer py.test+unittest runner over
> yet another unittest framework.

It's possible, but it would mean the project's maintainers lose a
decent amount of control over their work. As Laura Creighton said
earlier in this thread,

>> 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.

It's not just release cycles. You would also lose control over things
you might not expect, like what format your documentation is in. You
also give 75+ strangers the right to change your code at any time : )

Collin Winter