test.Client: provide os.environ with request.meta for consistency

[Daniel Hahler]

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 a comment to another issue, and since I appear to not miss something obvious, I am creating a new issue for it.)

[Tim Graham]

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?

[Daniel Hahler]

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?

[Aymeric Augustin]

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.

[Daniel Hahler]

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.

[Florian Apolloner]

Replying to 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.

[Tim Graham]

What I found in a quick search: according to ​PEP 333, "the environ dictionary may also contain arbitrary operating-system "environment variables" (it's a "may", not a "must").