[TIP] unittest & TDD

Kumar McMillan kumar.mcmillan at gmail.com
Mon Mar 12 09:20:24 PDT 2007

On 3/11/07, Collin Winter <collinw at gmail.com> wrote:
> * 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.

I'm just going to sneak this in (since you asked for feedback)...

I am strongly opposed to expecting a number of tests to run.  I think
it's a wart in the perl community and requiring this feature means
you've written a bad test (granted, this is also due to perl sucking
in how it captures errors).

If you have a loop in your test and you don't have a flag that asserts
the loop was run at all, you've written a bad test.  If I start seeing
python test suites that assert a number of tests were run, causing me
to update the hard-coded number if I want to add a new test, I'm going
to groan, VERY LOUDLY and will possibly even begin thrashing on the
floor chanting "I will not prove t/ I will not prove t/ I will not
prove t/" :(


PS. capturing TAP output would be about a 10 line nose plugin.  Since
you are talking about re-writing unittest, I'd suggest exposing the
right hooks for nose's plugin framework to be more flexible.

Also, I"m kinda with Titus on the "let extensions be extensions" trail.

And, besides bashing perl for other reasons, I agree with Grig about
supporting something like "make test" :)

More information about the testing-in-python mailing list