[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
fuzzyman at voidspace.org.uk
Wed Jul 16 22:48:54 CEST 2008
Raymond Hettinger wrote:
> From: "Michael Foord" <fuzzyman at voidspace.org.uk>
>> I assume this doesn't rule out the addition of [some of..] the new
>> convenience test methods?
> In Kent Beck's book on Test Driven Development, he complains that most
> unittest implementations spawned from his original work have grown far
> too complicated and would be better served by sticking to a simple
> framework for writing and running tests.
> Accordlingly, if a new test method gets added, it needs to add some
> signficant new capability. IMO, little "convenience" methods like
> self.assertLessThan() do not meet the criterion. Polluting the module
> with more methods makes it harder to fit into your head and does
> little to simplify the task of writing mountains of tests.
> If some people want to proceed down the path of "useful additions",
> I challenge them to think bigger. Give me some test methods that
> improve my life. Don't give me thirty ways to spell something I can
> already do.
I assert that... the following changes do meet those conditions:
assertRaisesWithMessage - for testing the error messages from library
functions, where the error message is part of the API under test (I'm
less convinced with the need for a regex matching version myself.)
Changes to assertEquals so that the failure messages are more useful
(telling you which member failed the comparison for collections and
showing a diff for long strings). This improves rather than adds.
assertIn / assertNotIn I use very regularly for collection membership
tests (although personally I find member, container to be a more
memorable order for the arguments - assert this is in that. The
comparison with assertRaises in the PEP is wrong - those parameters are
ordered so that the arbitrary number of arguments immediately follow the
callable they belong to.)
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.
These are the most important changes in my opinion.
assertIs / assertIsNot also sounds good, but is not something I would
miss if they weren't added.
More information about the Python-Dev