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

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

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/

More information about the Python-Dev mailing list