A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-April/078509.html below:

[Python-Dev] unittest's redundant assertions: assertsvs. failIf/Unlesses

[Python-Dev] unittest's redundant assertions: assertsvs. failIf/Unlesses [Python-Dev] unittest's redundant assertions: assertsvs. failIf/UnlessesTerry Reedy tjreedy at udel.edu
Wed Apr 9 05:47:34 CEST 2008
"Michael Foord" <fuzzyman at voidspace.org.uk> wrote in message 
news:47FB33C6.4080008 at voidspace.org.uk...
| > Someone please open a bug for this task.
| >
| >
| This sounds like a good compromise and I'm happy to take on the cleanup
| - unless someone else beats me to it. I guess it should wait until 3.0
| final is out of the door before adding the DeprecationWarnings.

I think, however, that the docs should be revised now, for 2.6/3.0.
In the list of methods under TestCase Objects, the preferred method of each 
pair (or triplit) should be given first and the others marked as future 
deprecations, not recommended for new test code.  The explanations of the 
methods should use the preferred names.  So failIf/assertFalse should be 
reversed in order (assuming that failIf is the one to go) and the text "The 
inverse of the failUnless() method" should be changed to "The inverse of 
the assertTrue() method" (if that is the one to be kept).

I would also (lesser priority) revise examples to only use the preferred 
names.  The would make things easiest for new unittest users that are not 
Java refugees.

tjr



More information about the Python-Dev mailing list

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