Issue 6966: Ability to refer to arguments in TestCase.fail* methods (original) (raw)

Created on 2009-09-22 09:28 by tuben, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg92977 - (view) Author: Johan Tufvesson (tuben) Date: 2009-09-22 09:28
In the unittest module, TestCase class: If one wants to provide a more descriptive fail message compared to the default, it is often valuable to be able to refer to the arguments evaluated by the fail*- (or assert*-) method. This can be accomplished by binding names to the evaluated values before the call to the fail*-methods, and then providing a string with the values embedded as needed. This, however, can be quite cumbersome when there are a lot of calls to fail*-methods. Today: Arg1 = RealValue() Arg2 = ExpectedValue() self.failUnlessEqual(Arg1, Arg2, "Got {0}, but expected {1}.".format(Arg1, Arg2)) Proposed solution: In the fail*-methods, check if the msg argument is some kind of string (basestring?), and run the format() method on the string with the supplied arguments. This would result in code like this: self.failUnlessEqual(RealValue(), ExpectedValue(), "Got {0}, but expected {1}.")
msg92983 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2009-09-22 11:11
The new longMessage class attribute on TestCase already shows both arguments when a call to assertEqual fails (the failUnless methods are now deprecated) - even if you supply a custom message.
msg92985 - (view) Author: Johan Tufvesson (tuben) Date: 2009-09-22 11:58
I admit that I had not seen the longMessage attribute. That is better than the present possibilities in 2.6, although not as configurable as my suggestion (but with better backwards compatibility). Personally I will be a user of the longMessage feature, dreaming of even more functionality.
msg108074 - (view) Author: Hari Krishna Dara (haridsv) Date: 2010-06-18 01:43
Changing unittest.TestCase.failUnlessEqual() to something like this will be very useful: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '==' operator. Argument msg could optionally include string format operators named "lhs" and "rhs" (e.g., "%(lhs)r") """ if not first == second: raise self.failureException, \ (msg or "%(lhs)r != %(rhs)r") % dict(lhs=10, rhs=20)
msg108075 - (view) Author: Hari Krishna Dara (haridsv) Date: 2010-06-18 01:44
Oops... the dict part should have been "dict(lhs=first, rhs=second)": def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '==' operator. Argument msg could optionally include string format operators named "lhs" and "rhs" (e.g., "%(lhs)r") """ if not first == second: raise self.failureException, \ (msg or "%(lhs)r != %(rhs)r") % dict(lhs=first, rhs=second)
msg220494 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-13 20:24
This appears to be me to be obsolete, given that long messages are now the default, and the message argument enhances the long message rather than replacing it.
History
Date User Action Args
2022-04-11 14:56:53 admin set github: 51215
2014-06-13 20:24:44 r.david.murray set status: open -> closednosy: + r.david.murraymessages: + resolution: out of datestage: resolved
2010-06-18 01:44:35 haridsv set messages: +
2010-06-18 01:43:07 haridsv set messages: +
2010-06-18 01:31:48 haridsv set nosy: + haridsv
2009-09-22 11:58:23 tuben set messages: +
2009-09-22 11:11:59 michael.foord set messages: +
2009-09-22 11:07:13 georg.brandl set assignee: michael.foordnosy: + michael.foord
2009-09-22 09:28:06 tuben create