I think using it as a prefix is a good solution. Updated the patch, and attached it to the ticket. Should we reopen the ticket?
On Oct 12, 11:36 am, Wes Winham <[email protected]> wrote: > I love the prefix idea. Seems like the best of both worlds. I also > agree that changing the name to either ``prefix`` or ``msg_prefix`` > would probably be preferable, to explicitly indicate that the behavior > is different than the standard msg argument. > > This would certainly satisfy my use case. > > -wes > > On Oct 11, 4:52 pm, Sean Bleier <[email protected]> wrote: > > > > > > > def assertFormError(self, response, form, field, errors, msg=None): > > > > ... > > > > self.fail(msg or "The field '%s' on form '%s' in context %d" > > > > " contains no errors" % (field, form, i)) > > > > would become: > > > > prefix = msg and "%s: " % msg or "" > > > self.fail("%sThe field '%s' on form '%s' in context %d" > > > " contains no errors" % (prefix, field, form, i)) > > > > This preserves the best of both worlds - a rich failure message, plus > > > the ability to add user-specific context to help identify the source > > > of the problem in the test suite. This does differ from the behavior > > > of the assert* functions in the standard library, but hopefully in a > > > way that makes sense under the circumstances. Opinions? > > > > Yours, > > > Russ Magee %-) > > > I like Russ's prefix idea. I believe Christian's concern is that the > > django's error messages do not give enough context for the programmer when > > debuging. Adding the prefix allows programmers to add that context without > > blindly overridding the error message that django throws. > > > Karen is right about the name of msg if it is going to serve as a prefix to > > the msg given to Python's assert* methods. Something like msg_prefix or > > prefix would be more appropriate IMO > > > Using Christian's example, I might change it to: > > > 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_prefix='Error in url %s' % url) > > > This way for the two cases in which assertNotContains can fail, you can have > > errors messages like: > > "Error in url /home/: Couldn't retrieve page: Response code was 404 > > (expected 200)" > > or > > "Error in url /home/: Response should not contain > > 'TEMPLATE_STRING_IF_INVALID" > > > --Sean --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
