Test if code is executed from within a py.test session

Solution 1:

A simpler solution I came to:

import sys

if "pytest" in sys.modules:
    ...

Pytest runner will always load the pytest module, making it available in sys.modules.

Of course, this solution only works if the code you're trying to test does not use pytest itself.

Solution 2:

There's also another way documented in the manual: https://docs.pytest.org/en/latest/example/simple.html#pytest-current-test-environment-variable

Pytest will set the following environment variable PYTEST_CURRENT_TEST.

Checking the existence of said variable should reliably allow one to detect if code is being executed from within the umbrella of pytest.

import os
if "PYTEST_CURRENT_TEST" in os.environ:
    # We are running under pytest, act accordingly...

Solution 3:

A solution came from RTFM, although not in an obvious place. The manual also had an error in code, corrected below.

Detect if running from within a pytest run

Usually it is a bad idea to make application code behave differently if called from a test. But if you absolutely must find out if your application code is running from a test you can do something like this:

# content of conftest.py
def pytest_configure(config):
    import sys
    sys._called_from_test = True

def pytest_unconfigure(config):
    import sys  # This was missing from the manual
    del sys._called_from_test

and then check for the sys._called_from_test flag:

if hasattr(sys, '_called_from_test'):
    # called from within a test run
else:
    # called "normally"

accordingly in your application. It’s also a good idea to use your own application module rather than sys for handling flag.

Solution 4:

Working with pytest==4.3.1 the methods above failed, so I just went old school and checked with:

if 'pytest' in sys.argv[0]:
  print('pytest was called!')

Solution 5:

While the hack explained in the other answer (http://pytest.org/latest/example/simple.html#detect-if-running-from-within-a-pytest-run) does indeed work, you could probably design the code in such a way you would not need to do this.

If you design the code to take the database to connect to as an argument somehow, via a connection or something else, then you can simply inject a different argument when you're running the tests then when the application drives this. Your code will end up with less global state and more modulare and reusable. So to me it sounds like an example where testing drives you to design the code better.