[TIP] unittest & TDD

[Titus Brown]

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?

(nose does about half of the things in the list, and we could easily
write extensions to do most of the rest. I assume py.test could also
easily be brought up to speed, too.)

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

cheers,
--titus