Add `response.text_content` to responses

[Adam Johnson]

A common pattern in tests is to make assertions on the response content. ​HttpResponse.content is bytes, requiring a call to .decode() for assertions with str values:

class DiggerLogTests(TestCase):
    def test_get(self):
        response = self.client.get('/digger/logs')
        assert 'Good digging' in response.content.decode()
        assert '2022-01-01 12:00:00' in response.content.decode()

This is suboptimal for a few reasons:

• It requires extra code.
• Mixed bytes/str errors may confuse beginners.
• decode() imparts a small but measurable overhead, especially if repeated for each assertion as above.
• .decode() defaults to UTF-8. Whilst this is by far the most common encoding, the response may actually use a different encoding, as per ​the content-type header.

I propose that responses from the test client include a new attribute, called text_content. This would be cached property returning content decoded into a str, per any charset in content-type.

This new attribute would allow the above test to be written as:

class DiggerLogTests(TestCase):
    def test_get(self):
        response = self.client.get('/digger/logs')
        assert 'Good digging' in response.text
        assert '2022-01-01 12:00:00' in response.text

text_content could be added either in HttpResponse directly or attached by the test client, like response.json(). I favour the first option a little more as it may come in useful outside of tests, and the cache invalidation when content is mutated would be easier.

The new attribute could also be used to simplify assertContains, ​which decodes on every call

I have wanted this for a while and Simon Willison suggested this feature ​to me on Twitter.

[Natalia Bidart]

I'm a big +1 for this one, I have suffered this multiple times in many projects.

One note though: the issue title and content proposes text_content for the new attr name, but the example uses text. I personally prefer text because it's shorter and the same that requests ​exposes.

[Adam Johnson]

Ah yeah, I went back and forth on that when writing the ticket. Okay, let’s do text.

[Adam Johnson]

Natalia, do you have any opinion on adding in HttpResponse versus patching in the test client?

[Natalia Bidart]

Thanks for asking Adam! I missed that question/inquiry from the original description. I see now why you chose "HTTP handling" as Component :-).

I agree with your sentiment to make this a new feature/attribute for HttpResponse, so I'll be switching the component back.

[Jae Hyuck Sa]

Hi! Sarah.

I’ve noticed that content.decode() is being used in many places within our current test code.
Do you think it would be necessary to make any modifications to this?

Example

• ​https://github.com/django/django/blob/5ed72087c450af1a5da138bdfa674a069cf3f09c/tests/sitemaps_tests/test_http.py#L32

[Sarah Boyce <42296566+sarahboyce@…>]

In 4a685bc:

Fixed #35727 -- Added HttpResponse.text property.

Signed-off-by: SaJH <wogur981208@…>

[Sarah Boyce <42296566+sarahboyce@…>]

In 0c81775:

Refs #35727 -- Updated response.content.decode calls to use the HttpResponse.text property.

Signed-off-by: SaJH <wogur981208@…>