[Django] #23006: test.Client: provide os.environ with request.meta for consistency
Django
-----------------------------------+--------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------
When using the test.Client the information from os.environ is not present
in request.META, although it will be there usually (runser/uwsgi/...).
This causes e.g. the `debug.technical_500_response` to look different when
accessed via the test client.
This is important for (advanced) testing, when you want to see if e.g.
`settings.SECRET_KEY` would end up in the rendered content: with the test
client it will currently never be there, although you have
`DJANGO_SECRECT_KEY` in the environment and this would show up when not
using the test client (via rendering of request.META).
(I have mentioned this in
[https://code.djangoproject.com/ticket/23004#comment:2 a comment to
another issue], and since I appear to not miss something obvious, I am
creating a new issue for it.)
--
Ticket URL: <https://code.djangoproject.com/ticket/23006>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I don't think it's a good idea to rely on `os.environ` in your tests.
Could you use `RequestFactory` and set `request.META` manually?
--
Ticket URL: <https://code.djangoproject.com/ticket/23006#comment:1>
Django
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
Well, I am not relying on `os.environ`, but want to test what the app /
Django makes out of it.
This is a bit like assuming that `settings` is being used in the tests
(apart from special cases like `settings.DEBUG`).
My example should make it clear: I do not want to mock anything, but see
what gets rendered from what's provided.
Knowing the internals of the test client I could manually extend
`request.META`, but then it's still not certain that it would be the same
as with a real environment.
I really think that the test client should provide the environment similar
to runserver / the wsgi adapter.
I am a bit uncertain here how the test client and live server
interact/behave in this regard.
Is this maybe more a case of using the live server (LiveServerTestCase) to
test against?
Does the live server setup the environment with `os.environ` like
`runserver`, or is it like with the test client?
--
Ticket URL: <https://code.djangoproject.com/ticket/23006#comment:2>
Django
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
I'm a bit skeptical of your use case. There's a fair chance that
DJANGO_SECRET_KEY will exist in prod even if it doesn't exist in test.
This sounds unsafe.
--
Ticket URL: <https://code.djangoproject.com/ticket/23006#comment:3>
Django
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
> I'm a bit skeptical of your use case. There's a fair chance that
DJANGO_SECRET_KEY will exist in prod even if it doesn't exist in test.
This sounds unsafe.
I set `SECRET_KEY` via the environment only (based on django-
configurations and envdir).
I know that a certain/different envdir on prod vs. dev has an impact, and
that's why I would like to be certain that the test client uses the same
metrics as the wsgi adapter.
This issue evolved out of the need that I wanted to test how Django
renders its exception template based on the user/environment.
Please note that this involves mocking/setting `client.store_exc_info` to
make the exception's template content available for the test.
Ref: https://github.com/pelme/pytest_django/issues/130 - see the test in
https://github.com/pelme/pytest_django/issues/130#issuecomment-48771382.
This is the basic foundation for other tests in this regard.
--
Ticket URL: <https://code.djangoproject.com/ticket/23006#comment:4>
Django
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by apollo13):
* cc: apollo13 (added)
Comment:
Replying to [comment:2 blueyed]:
> Knowing the internals of the test client I could manually extend
`request.META`, but then it's still not certain that it would be the same
as with a real environment.
Do you have any details if a WSGI adapter does have to provide those in
META? If not I don't see a strong argument for adding them.
--
Ticket URL: <https://code.djangoproject.com/ticket/23006#comment:5>
Django
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Testing framework | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* status: new => closed
* resolution: => wontfix
Comment:
What I found in a quick search: according to
[http://legacy.python.org/dev/peps/pep-0333/#environ-variables PEP 333],
"the environ dictionary may also contain arbitrary operating-system
"environment variables" (it's a "may", not a "must").
--
Ticket URL: <https://code.djangoproject.com/ticket/23006#comment:6>