Hi Karen,
Karen Tracey writes:
> On Fri, Feb 12, 2010 at 3:38 PM, Paul Rubel <pru...@bbn.com> wrote:
>
> > [snip]
>
> I can't get a test.client.Client.post()s raw_post_data to match what I
> > get using my browser and the test throws an exception about reading
> > more than the available bytes.
> >
> > Printing out the raw_post_data when my app is running under
> > './manage.py runserver'
> >
> > stderr.write( request.raw_post_data)
> >
> > I see the following:
> >
> > form-TOTAL_FORMS=2&form-INITIAL_FORMS=2&form-0-id=0&\
> > form-0-remove=on&form-1-id=2
> >
>
> You don't mention where this data is coming from. Based on that value, I
> guess it's a browser posting a <form> that has no enctype specified,
> therefore the enctype is defaulting to
> "application/x-www-form-urlencoded" (see:
> http://www.w3.org/TR/html401/interact/forms.html#h-17.3).
Ah ha. That's exactly it.
>
>
> > [snip]
> > However, when I try to post in a test using the following code
> >
> > raw_post =
> > 'form-TOTAL_FORMS=2&form-INITIAL_FORMS=2&form-0-id=0&form-0-remove=on&form-1-id=2'
> > bits = raw_post.split('&')
> > post_data = {}
> > for x in bits:
> > k,v = x.split('=', 1)
> > post_data[k] = v
> > print post_data
> > c = Client()
> > response = c.post('/profile/sw/0/remove_packages/', post_data)
> >
> >
> Here you have not specified a content_type for the test client post(). The
> test client does not default to sending the content as
> application/x-www-form-urlencoded, rather it defaults
> to multipart/form-data. That accounts for the difference in what is in the
> raw_post_data in your view.
Interesting that there's a disconnect there. Thank you for pointing it
out.
>
> Is your view really processing raw_post_data instead of using request.POST?
No, just using it to try to get some insight while debugging.
> If so then you probably want to specify
> content_type='application/x-www-form-urlencoded' on your c.post() call, and
> you want to pass in raw_post, not the post_data dictionary you create from
> it, because when you specify a content_type other than multipart/form-data
> then the test client just passes the post data as-is and does not attempt to
> format it in any particular way. See:
>
> http://docs.djangoproject.com/en/dev/topics/testing/#django.test.client.Client.post
That was it, changing the content_type and passing in the data 'as-is'
got the test running. Following the link, though, I can see how I got
confused. It claims that the following code:
c = Client()
>>> c.post('/login/', {'name': 'fred', 'passwd': 'secret'})
creates the following post data:
name=fred&passwd=secret
While this may be shorthand for people in the know I thought it looked
like (what I now know to be) x-www-form-urlencoded data as opposed to
the multipart/form-data that was actaully being sent via that post
call. Reading the page it's clear what's going on but the example is
confusing. Thank goodness for your timely and accurate help.
<snip>
>
> >
> > Also, is there a way to get the > output of print statements in
> > my view visible while running the tests > or do I need to use a
> > logger?
> >
> >
> Not sure why you don't see prints placed in views when running tests. They
> show up on the console with all the other output for me.
Interesting. My config must somehow be swallowing them. If I figure it
out I'll post what I find. I've currently moved to stderr.write but I
suspect a logging facility will go in shortly.
Thanks again,
Paul
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
