[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

[C. Titus Brown]

On Wed, Jul 16, 2008 at 02:03:29PM -0700, Raymond Hettinger wrote:
-> - self.assert_(func(x) in result_set)
-> + self.assertIn(func(x), result_set)
-> 
-> Yawn.  The gain is zero.  Actually, it's negative because the second
-> doesn't read as nicely as the pure python expression.

People are proposing these craptastic methods because 'assert' doesn't
do good reporting by default.  Maybe we can fix that instead??

-> >The run_tests function for running collections of tests. Almost every 
-> >project I've worked on has had an ad-hoc imnplementation of this, 
-> >collecting test modules and turning them into a suitable collection for 
-> >use with unittest.
-> 
-> Now, that's more like it.    Propose more cool stuff like this and
-> the module really will be improved.

At this point I might suggest taking a look at the nose and py.test
discovery rules and writing a simple test discovery system to find &
wrap 'test_' functions/classes and doctests in a unittest wrapper.

Many people use nose and py.test (which use remarkably similar test
discovery procedures, note) and the basic algorithm is pretty well
worked out.  And, since nose wraps such tests in unittests anyway, it
can be made entirely compatible with pre-existing TestRunner
derivatives.

This steers a middle ground between trying to co-opt py.test and nose
entirely (which no one would be happy with) and leaving the existing
(and hideous, IMO) unittest as the only "standard" option.  It also
helps out people who want to take advantage of some of the niftier
py.test/nosetests features during development but *also* want clean
test code that uses a standard library module.

Let me know if I should expand on this proposal...

Paranthetically, wrt unittest, the world seems to be divided into two
kinds of people : those who find the current API uninspiring but ok, and
those who absolutely hate it.  Has anyone said that they *love* the
current unittest API with all of its boilerplate?  If not, then I think
that says something, no?

--titus
-- 
C. Titus Brown, ctb at msu.edu