First off, thank you all for responding and discussing this issue.
Responding to Russell's comments on the quality of the patch, I agree
that it needs better test coverage. I've uploaded an updated patch
which covers all exit points of assertFormError. The better tests
confirm that the original patch2 works as intended.
I think I might not have explained well enough what the intention of
the msg argument is. The argument is a literal string, which is not
formatted with any arguments. This is consistent with the behavior of
the standard library unittest functions.
For example, on line 124 of the original The syntax is like this:
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))
Be aware of the difference here:
>>> msg = None
>>> msg or "foo%s" % "bar"
'foobar'
>>> msg = "test"
>>> msg or "foo%s" % "bar"
'test'
>>> (msg or "foo%s") % "bar"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: not all arguments converted during string formatting
As far as whether this is worth doing, the point of this patch is not
that the existing error messages are not descriptive enough. It is
that they cannot know the circumstances under which they will be
called in all cases. There may be very important bits of debugging
information that will never even be passed to the assert methods, or
be accessible from their scope. That is precisely the reason why the
methods like assertEquals in python have the extra msg parameter. They
could not have foreseen that the django library would use those msg
parameters in such creative ways to describe form errors and the like.
But the msg parameter handles it well, because it gives control to the
application programmer, who in general knows better than the library
developer what sort of error message he wants.
So everyone doesn't have to dig through the ticket messages, I'll
reprint the example I gave there.
This is a test that looks through a list of urls and checks that there
are no invalid template variables. Since the method assertNotContains
doesn't (and shouldn't) parrot back the url for the response, you
don't know what url failed, without using print statements or a
debugger.
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)
On Oct 8, 12:12 pm, Tobias McNulty <[email protected]> wrote:
> On Thu, Oct 8, 2009 at 11:58 AM, Wes Winham <[email protected]> wrote:
> > This gives me a nice little summary. I know that there were more foo's
> > displayed on the page than there should have been.
>
> I second that. The option to specify a quick message explaining what
> the failure means, for anyone who didn't write the test, can be the
> difference between a 2 minute fix and a half hour+ debugging session.
>
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (919) 951-0052http://www.caktusgroup.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
