Opened 9 years ago
Last modified 9 years ago
#26668 closed Bug
HTTPResponse.content is not unicode in context of test cases. — at Initial Version
Reported by: | Will Pimblett | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | 1.8 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Came across the following when adding from __future__ import unicode_literals
to my test.py-s
When doing the following for an existing view with an expected output:
def test_page_not_found(self): url = '/help/404/' c = self.get_client() response = c.get(url) self.assertIn("Page Not Found", response.content)
We get:
====================================================================== ERROR: test_page_not_found (xsd_help.tests.HelpViewTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builds/wjdp/xsacdb/src/xsd_help/tests.py", line 23, in test_page_not_found self.assertTrue("Page Not Found" in response.content) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 21370: ordinal not in range(128)
Workaround is to replace response.content
with unicode(response.content, encoding=settings.DEFAULT_ENCODING)
. According to what I could find in the docs the content should be encoded with uft-8, I think this issue is because request.content
is a bytestring without an encoding attached.
I'm raising this either in case this in not expected or if it is suggesting a more descriptive error is generated and/or better documentation for those who come across this - there was a *lot* of headscratching needed to find the root of these test failures.
Another suggestion: could we have another property of HTTPResponse that gives us a unicode string rather than a bytestring for test cases?
See http://stackoverflow.com/questions/36004324/function-assertin-causes-the-unicodedecodeerror/37456287 for another similar use case.