Updated docs: Now we can use environment variable PYTEST_VERSION to detect if a code is run by a pytest run

[dheerajck]

Add a better way to detect if a code is running from within a pytest run.

[dheerajck]

#9502 (comment)

[RonnyPfannschmidt]

The import check is actually a more fragile version a it also triggers whenever valid pytest Import was done

I recommend listing the import check as naive and the Hook based one as robust

[dheerajck]

Also sorry for too much force pushes

[dheerajck]

Converting to draft to see if there is a better way to check if a code is running from within pytest.

[nicoddemus]

Thanks @dheerajck, but I think the docs as is already shows a robust solution, why show an alternative (checking "pytest" in sys.modules) if the approach using pytest_configure is for all purposes better?

[dheerajck]

I dont want to add "pytest" in sys.modules as @RonnyPfannschmidt pointed out an issue with it, thats why I converted this PR to draft to check if theres a better approach

The approach in doc doesnt work in every case, this issue mentions one case where it doesnt work

pytest documents a pattern to change behaviour using fixtures here: https://docs.pytest.org/en/latest/example/simple.html#detect-if-running-from-within-a-pytest-run . Unfortunately this techinque is incompatible with this particular problem. pytest-django's fixtures load the settings module early, before fixtures from conftest.py fixtures run, so the pattern cannot be applied. And environment variable changes cannot be undone after the fact.

I think we should add an env for this purpose like mentioned in that issue by @The-Compiler

[dheerajck]

if maintainers would like to have that I can create a PR for that
#9502 (comment)

@nicoddemus

[nicoddemus]

if maintainers would like to have that I can create a PR for that

👍 by me!

I understand the concerns from @RonnyPfannschmidt in #9502 (comment):

Personally im -1 on adding easy and obvious fast paths to make it easy to keep messy global configuration around

While I agree in principle to avoid adding easy ways for people to do the wrong thing, in this case I think we should add this because:

1. Often people are stuck with previous design decisions (like importing environment variables during import) and they have no control over, they are just trying to do the best for their users and the projects without breaking the world.
2. It is trivial for us to add, no backward compatibility concerns.

For this reason I think we should go for it.

[RonnyPfannschmidt]

In that case I propose introducing a get-current-testrun-state kind of helper that return details like current item, current phase, stats as immutable entity
Exact names and details will need bike shedding

[nicoddemus]

But one of the requirements is to not having to import pytest at all, this goes against that.

[dheerajck]

yes, I would suggest to not force importing pytest in non ut codes
and configvar probably will not help when we use pytest xdist parallel workers for example
if we are adding a method to check if a code is run by pytest, I prefer it to work with all cases

I have added a pr for this change #12190
and if its merged after fixing / changing things, I will update this pr to update docs

[nicoddemus]

@dheerajck thanks for updating it.

But now that we have PYTEST_VERSION, wouldn't be better to just advertise that solution, is it has no downsides?

[dheerajck]

yes, I will update the docs with new changes

[dheerajck]

Hi sorry, kinda busy as I started to look for a new job

[dheerajck]

Done @nicoddemus

[nicoddemus]

Thanks @dheerajck!

outdated