Since `test.utils`'s `setup_test_environment()` and
`teardown_test_environment()` already have a pattern of storing and
restoring environment values, I propose that this be addressed by adding a
`debug` argument to `test.utils.setup_test_environment()` that
`DiscoverRunner.setup_test_environment()` can then use.
Alternatively, `test.utils.setup_test_environment()` could take
responsibility for setting `DEBUG` to false.
--
Ticket URL: <https://code.djangoproject.com/ticket/27019>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_docs: => 0
* type: Bug => Cleanup/optimization
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
Is it a practical problem? Typically, more Django code doesn't run at the
end of a test run. I guess the argument to `setup_test_environment()` is
okay as long as it defaults to `debug=None` (i.e. don't change the value)
for backwards compatibility.
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:1>
Comment (by cjerdonek):
No, it hasn't been a practical problem for me. But I think it will help
conceptually and for consistency to have this logic in one place.
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:2>
Comment (by cjerdonek):
I posted a pull request for this
[https://github.com/django/django/pull/7025 here] on GitHub.
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:3>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:4>
* needs_better_patch: 0 => 1
Comment:
Left a few comments for improvement.
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:5>
* owner: nobody => cjerdonek
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:6>
Comment (by cjerdonek):
I'm still thinking about the best way to test (and whether to test for the
purposes of this patch).
If possible, I'm thinking it would be better to make the function itself
more testable (e.g. by dependency injection) or perhaps by patching. But
both of those approaches would be considerably more work than calling
`teardown_test_environment()`, as there are a number of objects in play
(e.g. the `settings` object, the `_SavedSettings` object, the `Template`
class, the `mail` and `request` modules, `deactivate()`, etc). In a later
ticket, it would be straightforward to switch from using the "arbitrary"
modules to the `_SavedSettings` object. That would at least be a
simplification, and would make it easier to test directly via patching or
dependency injection.
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:7>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:8>
Comment (by timgraham):
Yes, I think switching things over to `_SavedSettings` and then using
`@mock.patch('django.test.utils._SavedSettings')` (or whatever the correct
incantation of that is) might be the way to go.
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:9>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"7f9fd42b9316e4beddb690bae61940e940281805" 7f9fd42]:
{{{
#!CommitTicketReference repository=""
revision="7f9fd42b9316e4beddb690bae61940e940281805"
Fixed #27019 -- Made teardown_test_environment() restore the old DEBUG.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27019#comment:10>