classification
Title: Ability to refer to arguments in TestCase.fail* methods
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: michael.foord Nosy List: haridsv, michael.foord, r.david.murray, tuben
Priority: normal Keywords:

Created on 2009-09-22 09:28 by tuben, last changed 2014-06-13 20:24 by r.david.murray. 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
2014-06-13 20:24:44r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg220494

resolution: out of date
stage: resolved
2010-06-18 01:44:35haridsvsetmessages: + msg108075
2010-06-18 01:43:07haridsvsetmessages: + msg108074
2010-06-18 01:31:48haridsvsetnosy: + haridsv
2009-09-22 11:58:23tubensetmessages: + msg92985
2009-09-22 11:11:59michael.foordsetmessages: + msg92983
2009-09-22 11:07:13georg.brandlsetassignee: michael.foord

nosy: + michael.foord
2009-09-22 09:28:06tubencreate