#12226 closed (fixed)
Test HttpResponse template attribute needlessly hard to use
Reported by: | Carl Meyer | Owned by: | Carl Meyer |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Keywords: | sprintSep2010 | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
The template
attribute of the response objects returned by Django's test client might be a single template object or might be a list of template objects, depending whether template inheritance was used. If one tries to write tests that are usable in the presence of user-overridden templates, this results in noisy boilerplate in the tests:
response = client.get('/') try: template_name = response.template.name except AttributeError: template_name = response.template[0].name
There's no need for all this: the attribute should simply always be a list, sometimes of length 1.
I would suggest that a new attribute templates
could be added which is always a list, and the old attribute template
could go through the usual deprecation cycle.
I'll work on a patch if this approach is accepted in principle.
Attachments (2)
Change History (9)
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
by , 14 years ago
Attachment: | 12226_r13760.diff added |
---|
by , 14 years ago
Attachment: | 12226_r13760.2.diff added |
---|
comment:2 by , 14 years ago
Has patch: | set |
---|---|
Keywords: | sprintSep2010 added |
Owner: | changed from | to
Version: | 1.1 → SVN |
Attached patch starts response.template on deprecation path with PendingDeprecationWarning, and adds response.templates API that is always a list, whether empty, length 1, or longer.
I wasn't sure what the policy is for tests in a case like this. The patch includes conversion of most tests to the new API, and addition of a couple new tests to verify the back-compat API still works. Alternatively, the current trunk tests still all pass unchanged if only the non-test portion of the patch is applied, so if the policy is to wait to convert tests until PendingDeprecation becomes Deprecation, that's easily done as well.
Git branch (same as patch) at http://github.com/carljm/django/commits/ticket_12226
comment:3 by , 14 years ago
milestone: | → 1.3 |
---|
comment:4 by , 14 years ago
Needs documentation: | set |
---|---|
Patch needs improvement: | set |
Me likey.
However, this patch needs docs. We're deprecating a feature, so:
- We need to put an entry in the release notes.
- We need to put an entry in internals/deprecation.
comment:5 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Sounds like this may be something we want to do similar to how context is accessed.
http://docs.djangoproject.com/en/dev/topics/testing/#django.test.client.Response.context