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

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.
Michael
>> Raymond

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/