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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4