[TIP] unittest & TDD
collinw at gmail.com
Sun Mar 11 21:34:07 PDT 2007
On 3/11/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> On Sun, 11 Mar 2007 21:56:37 -0500, Collin Winter <collinw at gmail.com> wrote:
> > [snip]
> >I'm not so much looking for code as I am for ideas.
> > [snip]
> >So, let me have any ideas you may have, any grievances and grudges you
> >may hold against the existing unittest.
> I'm not a particularly big fan of Joel, and I certainly don't think he's
> right all the time, but this whole idea gives me a strong urge to link to
> this post:
> (so I just did).
> The stdlib unittest module is not the greatest software around, but it's far
> from unfixable. Please don't write something new. Please improve what we
> have already. Please don't use Py3k as a reason to discard what we already
> have, particularly for a library where the changes in Py3k will make not a
> single difference.
> Collecting a list of grievances and grudges about the unittest module is a
> great idea anyway, but such a list can be used to fix what we have instead
> of as a basis for starting over.
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.
More information about the testing-in-python