Re: Testing uploads and content types

2009-01-23 Thread Julien Phalip

On Jan 24, 12:57 pm, Malcolm Tredinnick 
wrote:
> On Fri, 2009-01-23 at 12:15 -0800, Julien Phalip wrote:
> > On Jan 24, 2:45 am, varikin  wrote:
> > > The UploadedFile[1] object has a field called content_type. So if you
> > > have this in a form:
>
> > > myfile = request.FILES['some_file']
> > > if myfile.content_type != 'application/zip':
> > >      #raise error
>
> > > I don't know if this will help you in your test. I hope it does.
>
> > > [1]http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#upload...
>
> > > John
>
> > Hi John,
>
> > Thanks for your reply. The snippet you've given is the kind of things
> > my view already does. The problem is that, when testing with
> > self.client.post(), all files are systematically encoded as
> > 'application/octet-stream'. To test the behaviour of my view I need to
> > control the content type of each uploaded files. And it doesn't seem
> > like there's another way than creating a custom request from scratch
> > to achieve that. Is that correct?
>
> That sounds quite believable. After all, you are simulating what a
> browser (or other HTTP client) has to do, which includes setting the
> content type. You'll probably want to write a utility function for
> creating your requests to make your code shorter, but it seems
> reasonable that this is something you have construct. Asking Django's
> test framework to do MIME-type detection by default would take time and
> remove an element of predictability (and even correctness) from the
> tests.
>
> If you come up with a neat, unobtrusive helper function, you might want
> to consider creating a patch for Django's test module.

Just for the record, I created a ticket with patch here:
http://code.djangoproject.com/ticket/10115

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---



Re: Testing uploads and content types

2009-01-23 Thread Malcolm Tredinnick

On Fri, 2009-01-23 at 12:15 -0800, Julien Phalip wrote:
> On Jan 24, 2:45 am, varikin  wrote:
> > The UploadedFile[1] object has a field called content_type. So if you
> > have this in a form:
> >
> > myfile = request.FILES['some_file']
> > if myfile.content_type != 'application/zip':
> >  #raise error
> >
> > I don't know if this will help you in your test. I hope it does.
> >
> > [1]http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#upload...
> >
> > John
> 
> Hi John,
> 
> Thanks for your reply. The snippet you've given is the kind of things
> my view already does. The problem is that, when testing with
> self.client.post(), all files are systematically encoded as
> 'application/octet-stream'. To test the behaviour of my view I need to
> control the content type of each uploaded files. And it doesn't seem
> like there's another way than creating a custom request from scratch
> to achieve that. Is that correct?

That sounds quite believable. After all, you are simulating what a
browser (or other HTTP client) has to do, which includes setting the
content type. You'll probably want to write a utility function for
creating your requests to make your code shorter, but it seems
reasonable that this is something you have construct. Asking Django's
test framework to do MIME-type detection by default would take time and
remove an element of predictability (and even correctness) from the
tests.

If you come up with a neat, unobtrusive helper function, you might want
to consider creating a patch for Django's test module.

Regards,
Malcolm



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---



Re: Testing uploads and content types

2009-01-23 Thread Julien Phalip

On Jan 24, 2:45 am, varikin  wrote:
> The UploadedFile[1] object has a field called content_type. So if you
> have this in a form:
>
> myfile = request.FILES['some_file']
> if myfile.content_type != 'application/zip':
>      #raise error
>
> I don't know if this will help you in your test. I hope it does.
>
> [1]http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#upload...
>
> John

Hi John,

Thanks for your reply. The snippet you've given is the kind of things
my view already does. The problem is that, when testing with
self.client.post(), all files are systematically encoded as
'application/octet-stream'. To test the behaviour of my view I need to
control the content type of each uploaded files. And it doesn't seem
like there's another way than creating a custom request from scratch
to achieve that. Is that correct?

Thanks,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---



Re: Testing uploads and content types

2009-01-23 Thread varikin


On Jan 23, 1:39 am, Julien Phalip  wrote:
> I have a view which processes a multi-part form and whose behaviour
> varies depending on the content types of the uploaded files. I've
> written some tests for that view as follows:
>
>         post_data = {
>             'name1': 'blah',
>             'file_field1': image_data,
>         }
>         response = self.client.post('/upload/', post_data)
>
> But the problem is that (apparently by design) all files are
> systematically encoded with the content type 'application/octet-
> stream'.
>

> Is there a more concise or more elegant way to do?
>

The UploadedFile[1] object has a field called content_type. So if you
have this in a form:

myfile = request.FILES['some_file']
if myfile.content_type != 'application/zip':
 #raise error

I don't know if this will help you in your test. I hope it does.

[1] 
http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#uploadedfile-objects

John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---



Testing uploads and content types

2009-01-22 Thread Julien Phalip

Hi,

I have a view which processes a multi-part form and whose behaviour
varies depending on the content types of the uploaded files. I've
written some tests for that view as follows:

post_data = {
'name1': 'blah',
'file_field1': image_data,
}
response = self.client.post('/upload/', post_data)

But the problem is that (apparently by design) all files are
systematically encoded with the content type 'application/octet-
stream'.

I have found a way around that, but only by writing a very long piece
of code to create a customised request from scratch:

payload = []
payload.extend([
'--' + client.BOUNDARY,
'Content-Disposition: form-data; name="name1"',
'',
'blah'
])
payload.extend([
'--' + client.BOUNDARY,
'Content-Disposition: form-data; name="file_field1";
filename="image1.png"',
'Content-Type: image/png',
'',
image_data
])
payload.extend([
'--' + client.BOUNDARY + '--',
'',
])
payload = "\r\n".join(payload)

r = {
'CONTENT_LENGTH': len(payload),
'CONTENT_TYPE':   client.MULTIPART_CONTENT,
'PATH_INFO':  "/upload/",
'REQUEST_METHOD': 'POST',
'wsgi.input': client.FakePayload(payload),
}
response = self.client.request(**r)

Is there a more concise or more elegant way to do?

Thanks a lot for your help,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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
-~--~~~~--~~--~--~---