Raymond Hettinger wrote:
From: "Michael Foord" <[EMAIL PROTECTED]>
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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
