Testing with global context-provided code

[ohad-griiip]

My tests structure looks like this -

tests/
    __init__.py
    test_no_mocked_library.py
    tests_with_mocked_library/
        conftest.py
        ....

In the nested conftest I use the pytest_collectstart like this -

def pytest_collectstart(collector):
    os.environ['API_KEY'] = '...'
    sys.modules['somelib'] = Mock()

Without this the tests wouldn't run (the code there're importing would raise).
Using this hook I manage to run those tests but then the mocked library remains mocked also in test_no_mocked_library which causes a different problem.

I didn't find an opposite hook to pytest_collectstart to use for cleanup.
Is there a way to be able to make all those tests pass together?

[RonnyPfannschmidt]

I would strongly recommend a scoped fixture, hacks with sys. Modules make for fragile tests, and I typically strongly recommended against them

[ohad-griiip]

BTW, though playing with sys modules may not be good practice I thought maybe I could do something like -

# conftest.py

def pytest_generate_tests():
   for module in {module in sys.modules if module.startswith('mypackage')}:
       sys.modules.pop(module)

So python would reimport the package before each test thus getting the "context" created again each time.
Didn't try it yet perhaps it can slow down the process, though I may ended up with sub tests packages each one setting up the configuration of the code (via env variables or something like this) for its tests and do this modules popping only before the collecting phase.

[RonnyPfannschmidt]

in general its dangerous and error prone to remove items from sys.modules

as for the handle_something function - code like that is just a time bomb - if not managed well, at some point you will just confidentially run destructive code against the wrong configuration

as for not explicitly passing things,
objects and methods exist for a reason,

as for "globalized events" sqlalchemy has prime examples of making it sensible

from .config import MyConfig
import pytest

class Myhandler:
   config: MyConfig
   
   def handle_something(self):
      wait_for_something(timeout=self.config.timeout)

def get_config_for_test(request: pytest.FixtureRequest):
   return MyConfig(...)
      
@fixture
def my_handler(request: pytest.FixtureRequest) ->  MyHanbdler:
   return MyHandler(get_config_for_test(request))
   
def test_something(my_handler: MyHandler):
  my_handler.handle_something()

[ohad-griiip]

Ok let me share a use case I have -
I have a reactive configuration meaning that one can subscribe for changes something like this -

# settings.py

class Config:
    x: ...
    y: ...

# module.py

cfg = get_config()

class Device:
    def __init__(self):
        ...

    @cfg.subscribe('x')
    def handle_x_change(prev, current):
        ...

The reactivity is something I need and I thought this could be a good/declarative implementation.
If I understand you correctly you would go for handing a configuration object to Device.__init__ instead of calling the get_config and then I could register callbacks without the decorator style, correct?

But then what happens code-wise when this piece calls another one and passes it the configuration (of some sub fields of it)...
If I have an api module for example which is also kind of global should it be a class that gets a config object instead of functions and then other classes/functions should be handed this api?
Perhaps it's not too bad and I just need to accept and get used to it, if you say this pattern is better I'll take your word on it.

[RonnyPfannschmidt]

It can be turned declarative without needing globals, but then one needs to actually have a layer in place that takes the declaration and runs the registration

An example of such a toolkit is the dectate library, however it is not widely used

It can be error prone to have a process /app continuously converge after config changes,
My personal preference is to start new processes, that however may not fit the use case with devices you outline

[ohad-griiip]

I took I little time to think about it and got into the conclusion that the code I have is simply unrightfully nested and needs to be organized and simplified. I understand why I should avoid touching sys.modules and having global objects that can make it harder to have isolated tests.
After thinking I think that probably the cases where one truly can pick up provider and context hierarchy is when having really nested objects like UI, but not in other scenarios.

Thanks for the insights @RonnyPfannschmidt!