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

Created on 2009-09-22 09:28 by tuben, last changed 2010-06-18 01:44 by haridsv.

Messages (5)
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)
History
Date User Action Args
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