For my own future reference, as well as to attract people to the fairly high signal testing-in-python mailing list, here are some particularly interesting posts to the TIP list.

Raphael Marvie implements a simple textual specification -> test suite generator.

Kumar McMillan makes some nice suggestions for Michal's "spec" nose plugin.

Benji York outlines a "Testing in Zope 3" case study (originally asked for by Grig).

Sebastien Douche discusses the reason he likes to use Trac to manage projects.

Kumar McMillan talks about the nosetrim plugin for suppressing duplicate errors in your nose output.

And last but not least, Grig starts a loooong discussion on "Doctest or unitest?" that has some really excellent responses; see especially Jim Fulton discusses doctests with setup/teardown in footnotes, Benji York posts the Platonic Ideal of doctests, and Benji York makes the case for good APIs (and zope.testbrowser and twill, too.

One less pleasant surprise was finding out that unittest is being rewritten for Py3K, and Collin is going with something that is both a significant rewrite and neither nose or py.test. The mind boggles.

Why are we extending a module based on an ugly paradigm (the unittest module is great, but it's got a lot of unnecessary syntactic sugar compared to nose/py.test), creating Yet Another unittest system, breaking people's old unittest extensions, and skipping past two fairly popular testing frameworks? Apparently this route is easier than either letting things be or convincing the nose/py.test people to "donate". I don't have anything against Collin, but is he really going to develop something that's significantly better than what's out there already? I'm particularly unhappy that it's going to be dropped into Py3K; I'm still not sure why this is happening. (Can anyone point me to a discussion?)

My preference would be to leave unittest as-is if we can't appropriate nose or py.test.

Anyway, I argued my point on the list, and no one else seems to be worried about it (or, rather, they don't have a solution ;).

--titus

Legacy Comments

Posted by Ian Bicking on 2007-03-20 at 14:04.

Yeah, the arguments for a reimplementation are very weak.  Yes, having
external libraries isn't great.  So... maybe the answer is to adapt
one of those libraries; that's certainly not a justification for
writing a new one.  nose would be much easier in these terms, as
py.test integrates with lots of stuff in the py-lib that isn't really
stdlib-ready.      Rewriting **again** would be silly.  And I don't
think the nose author is so territorial that changes to make it
appropriate for the stdlib would be a problem.    Of course, then
there's the question of release cycles and the stdlib and how any of
that fits together.  But reimplementation doesn't solve anything there
either.

Posted by Mike Verdone on 2007-03-20 at 19:15.

I haven't heard anything lately about the rewrite on the Py3k list.
Maybe they forgot about it? :)    Generally I've found the unittest
module as-is is good enough. The hard part is convincing the
developers to write the tests. I don't really care too much which
framework is "best". I hope the old unittest module lives on in Py3k
somehow.    One strong point of unittest is that it looks a lot like
JUnit. Less of a learning code if you've already learned to handle
that beast.

Posted by Titus Brown on 2007-03-20 at 19:22.

I agree with both of you ;)