Opened 15 years ago

Closed 14 years ago

Last modified 12 years ago

#10314 closed (fixed)

TestCase assert methods do not accept a msg parameter

Reported by: wwinham Owned by: nobody
Component: Testing framework Version: 1.0
Severity: Keywords:
Cc: christian.oudard@… Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Attachments (5)

assert_msg_patch (4.4 KB ) - added by christian.oudard@… 14 years ago.
patch2 (10.8 KB ) - added by christian.oudard@… 14 years ago.
different way of doing it, without the method decorators
patch_better_unittests (13.5 KB ) - added by christian.oudard@… 14 years ago.
better unittests vs. patch2
msg_prefix_patch (19.2 KB ) - added by christian.oudard@… 14 years ago.
Prefixes error messages with custom message instead of replacing it
patch_with_docs (22.0 KB ) - added by christian.oudard@… 14 years ago.
Added documentation for msg_prefix

Download all attachments as: .zip

Change History (16)

comment:1 by Alex Gaynor, 15 years ago

Triage Stage: UnreviewedAccepted

No reason we shouldn't keep the same API.

in reply to:  1 comment:2 by sebleier, 15 years ago

Resolution: invalid
Status: newclosed

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.

by christian.oudard@…, 14 years ago

Attachment: assert_msg_patch added

comment:3 by christian.oudard@…, 14 years ago

Resolution: invalid
Status: closedreopened

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.

by christian.oudard@…, 14 years ago

Attachment: patch2 added

different way of doing it, without the method decorators

comment:4 by christian.oudard@…, 14 years ago

Has patch: set

comment:5 by Russell Keith-Magee, 14 years ago

Resolution: wontfix
Status: reopenedclosed

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.

comment:6 by christian.oudard@…, 14 years ago

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

comment:7 by Russell Keith-Magee, 14 years ago

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

by christian.oudard@…, 14 years ago

Attachment: patch_better_unittests added

better unittests vs. patch2

by christian.oudard@…, 14 years ago

Attachment: msg_prefix_patch added

Prefixes error messages with custom message instead of replacing it

comment:8 by Russell Keith-Magee, 14 years ago

Needs documentation: set
Resolution: wontfix
Status: closedreopened

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.

comment:9 by Russell Keith-Magee, 14 years ago

milestone: 1.2

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

by christian.oudard@…, 14 years ago

Attachment: patch_with_docs added

Added documentation for msg_prefix

comment:10 by Russell Keith-Magee, 14 years ago

Resolution: fixed
Status: reopenedclosed

(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.

comment:11 by Jacob, 12 years ago

milestone: 1.2

Milestone 1.2 deleted

Note: See TracTickets for help on using tickets.
Back to Top