TestCase assert methods do not accept a msg parameter

[wwinham]

django.test.TestCase assert methods, such as assertContains, do not accept a failure message as their final parameter, like the underlying unittest methods do.

[Alex Gaynor]

No reason we shouldn't keep the same API.

[sebleier]

Replying to Alex:

No reason we shouldn't keep the same API.

Django's test cases have the possibility of having more than one Exception being raised so it doesn't make sense for a single message to characterize the failure of the test.

[christian.oudard@…]

Attached a patch which adds msg parameters to all django test case assert* functions.

I didn't understand at first what you meant by having more than one exception raised, but now that I got into the code, I do. There are multiple ways that each assert method can fail. For example, in assertContains, it could have the wrong status code, not contain the text, or not contain the text the correct number of times. Each of these three outcomes has a different default message.

However, I believe that there are cases where each of the default messages is inadequate. Take for example, a test that looks through pages for invalid template variables:

class TemplateTestCase(ClientTestCase):
    def testTemplateError(self):
        urls = [
            '/',
            '/home/',
            '/admin/',
            # etcetera ...
        ]
        for url in urls:
            response = self.client.get(url, follow=True)
            self.assertNotContains(
                response,
                settings.TEMPLATE_STRING_IF_INVALID,
                msg='Found an invalid variable in url %s' % url)

Without the message parameter, it would require print statements to determine which url actually failed.

[christian.oudard@…]

different way of doing it, without the method decorators

[Russell Keith-Magee]

As sebleier noted, this is an ill-posed request. Assertions like assertFormError raised many different error messages, so a simple one-message parameterization will be insufficient.

If there is a problem with a specific error message (as is suggested by comment 3), the the solution is to fix that error message. Suggestions welcome.

[christian.oudard@…]

How would you suggest handling use cases such as the above code snippet without a msg parameter?

[Russell Keith-Magee]

If you want to discuss a wontfix, the right place is django-dev.

[christian.oudard@…]

better unittests vs. patch2

[christian.oudard@…]

Prefixes error messages with custom message instead of replacing it

[Russell Keith-Magee]

Reopening following discussion on django-dev that resolved to use the extra argument as a prefix to the internally generated error message of the assertions.

[Russell Keith-Magee]

Marking as v1.2 so I remember to check this in.

[christian.oudard@…]

Added documentation for msg_prefix

[Russell Keith-Magee]

(In [12273]) Fixed #10314 -- Added a message prefix argument to Django's test assertions. Thanks to Wes Winham for the original suggestion, and Chistian Oudard for the patch.

[Jacob]

Milestone 1.2 deleted