[Python-Dev] unittest's redundant assertions: assertsvs. failIf/Unlesses (original) (raw)
Terry Reedy tjreedy at udel.edu
Wed Apr 9 05:47:34 CEST 2008
- Previous message: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
- Next message: [Python-Dev] unittest's redundant assertions: assertsvs. failIf/Unlesses
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"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
- Previous message: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
- Next message: [Python-Dev] unittest's redundant assertions: assertsvs. failIf/Unlesses
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]