[TIP] unittest & TDD

Collin Winter collinw at gmail.com
Sun Mar 11 21:24:21 PDT 2007


On 3/11/07, Titus Brown <titus at caltech.edu> wrote:
> On Sun, Mar 11, 2007 at 09:56:37PM -0500, Collin Winter wrote:
> -> Python 3000 will happen sooner than you think. Our goal is to get the
> -> first alpha out sometime this summer, with 3.0 to follow in the first
> -> half of 2008. With that in mind, I think the time to talk about new
> -> test loading and loading strategies is *now*, not a couple of years
> -> from now. The more input I get now, the less chance there is of me
> -> having to rewrite unittest *again* for Python 4K.
> ->
> -> I'm not so much looking for code as I am for ideas. The more ideas
> -> about test discovery/running/reporting/etc I have in hand, the more
> -> data points I have to work from when figuring out how this thing
> -> should operate. A sampling of the use-cases/extensions I'm working
> -> with now:
> ->
> -> * supporting refcount checking around each test.
> -> * marking certain tests as TODO.
> -> * skipping certain tests based on boolean criteria.
> -> * formatting test results a la the current unittest.
> -> * writing test results to an XML file.
> -> * emitting TAP (Perl's Test Anything Protocol) for a test run.
> -> * making sure you ran the expected number of tests.
>
> Hi, Collin,
>
> when confronted by this list... my main question is "why?"  What
> advantages are there in duplicating large chunks of functionality
> that are in other packages?
[snip]
> So, why this effort on upgrading unittest?  I like everything on the
> list, but it seems like you're creating yet another testing
> framework that's going to be incompatible with everything else ;).

To clarify, the things on that list aren't necessarily going into
unittest: I'm using them like landmarks to triangulate off on. They
serve as tests of refactoring ideas, with ease of implementation as
the benchmark.

Now, to why I'm doing this. The main reason is that the current
unittest design sucks if you're doing anything more complicated than
"subclass TestCase, run tests", anything like, say, implementing the
extensions I listed. The fact that it sucks wouldn't be so bad except
that it's in Python's standard library, which means that it's the
default starting point for anyone wanting to write tests in Python.
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.

Collin Winter



More information about the testing-in-python mailing list