On Wed, Oct 7, 2009 at 11:15 PM, Christian Oudard <[email protected]> wrote: > > I wanted to get some feedback from the mailing list about a patch I > wrote. There are two approaches I tried, and attached them both to > this ticket: > > http://code.djangoproject.com/ticket/10314 > > Quick explanation: Basically, the assertFoo methods in the python > stdlib test case class accept a "msg" parameter, to customize the > failure message given. The methods like this in django do not accept > this parameter to pass it along. I think they should, and I gave an > example in the ticket. > > The ticket was originally closed as invalid by sebleier. The reason he > gave is that the django assertFoo methods can fail in a variety of > ways, whereas the python assert methods can only fail in one way. > While this is an important thing to keep in mind when writing test > cases, I still think that it is useful to be able to customize the > error message, so I wrote the patch.
I'm inclined to agree with sebleier here - for the simple reason that your patch won't work. If your patch had a comprehensive test suite, you would discover this very quickly. Consider your patch2 on the ticket, and a call to assertFormError(). Line 117 - 5 arguments, (field, form, i, err, field_errors) Line 124 - 3 arguments, (form, i, field) Line 135 - 4 arguments, (form, i, err, non_field_errors) Line 140 - 1 argument, (form) There is no way for you to provide a msg argument that will meet all these argument lists. One solution might be to use keyword substitution rather than positional substitution (i.e., format errors like "There was an error on %(form)s"), but that doesn't address the problem of having a single error message string that is meaningful across 4 different uses. I've picked on assertFormError here, but similar arguments apply to the other Django assertions. Looking more philosophically - there is a significant difference between assertTrue and assertFormError. assertTrue is a general logical principle. Knowing X != True doesn't necessarily explain a problem. However, forms fail in very predictable ways, so we are in a position to embed meaningful error messages, and Django's error messages are generally pretty meaningful, IMHO. Looking at the ticket, it appears that your actual problem is that some of the messages raised by Django aren't meaningful enough. If this is the case, then the solution is to fix the actual error message in question. Feel free to suggest specific improvements. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
