Testing code that relies on context vars without a full test client / app

[shevron]

Sometimes it can be very useful to write tests for functions that rely on some data in the request context, but without using a full Starlette test client, as tests that are based on test clients are much less "lean" and do a lot of things beyond just running the code unit under test.

I think it would be very useful to document / add some helpers that enable a context manager that mocks a request / response cycle / middleware / etc. so it can be used in testing.

For now, I have done this in my tests (I'm using pytest fixtures, this is a very simplified example):

code under test

from starlette_context import context

def get_session_id():
    """Get the current session ID"""
    return context['session_id']

in conftest.py:

import pytest
from starlette_context import _request_scope_context_storage, context


@pytest.fixture()
def request_context():
    token = _request_scope_context_storage.set({})
    try:
        yield context
    finally:
        _request_scope_context_storage.reset(token)

in tests:

from myapp.session_utils import get_session_id 


def test_some_func_that_relies_on_context(request_context):
    request_context['session_id'] = 'foobar'
    assert get_session_id() == 'foobar'

Obviously, this is a bit hackish and it would be nice if there would be an official / documented way of doing this without accessing module internals.

[tomwojcik]

Thanks for opening the ticket.

I have mixed feelings about adding such a thing. In bigger libraries, you can often find dummy classes with implementation specifically for testing/dev. For example, a mail client that won't send actual emails though it acts as if the mail has been sent. Can you give an example of a library that is actually distributing a mock as part of its package?

Another reason why I don't think it's a good idea - pytest. If it has to be reusable, then pytest shouldn't really be used as it's not a built-in library. On the other hand, I think there used to be problems with mixing pytest fixtures with unittest.mock, so I'm not sure built-in mock would be useful for people using pytest.

I wrote this mock 2 years ago.

starlette-context/tests/test_context/test_mocked_context_object.py

Lines 13 to 17 in 4550a19

	def mocked_context(monkeypatch, ctx_store) -> _Context:
	monkeypatch.setattr(
	"starlette_context.ctx._Context.data", ctx_store.copy()
	)
	return _Context()

We're doing similar things differently. You set actual ContextVar while I only mock the storage of starlette-context context object, which would otherwise access ContextVar.

I'm not saying your request is a bad idea but maybe a ContextForTesting object would be better, which would work exactly the same but would store all the data after the request-response cycle has ended?

[hhamana]

I have to admit to using a similar fixture setting the context directly, although also made to pass a dict in to set the context with from tests.
such a case should be common enough that it does make sense to provide something to test with data in the context in a simple unit test situation.
a public pytest fixture could be exposed to do that. a context manager might also make sense.

[shevron]

Thanks for the reply. To clarify, I posted my code as an example of a pytest-specific solution, I agree it's not a good idea for you to provide a pytest-specific solution. But anything that is essentially a context manager that sets and resets the context on entry / exit would be easily usable in almost any testing context.

I think providing some hooks or utilities that facilitate testing is a great practice, for any library. I can probably find a few good examples of libraries that do this, but TBH I really think that in the case of starlette-context there isn't much that needs to be done other than exposing some non-private API that wraps _request_scope_context_storage. It can be as simple as a 4-line context manage.

I am not a fan of monkeypatching anything unless it is absolutely necessary, and in this case I don't think it is. It means there's more divergence between real behavior and the tested code, and ultimately could cause tests to continue passing even if actual code fails, in cases where the patched code changed significantly (e.g. with API changes).

I'm not sure how using the suggested ContextForTesting solution would look like in tests. Can you give an example?

TBH I think providing this testing hook could be kept really simple. For what I need, I agree with @hhamana 's last suggestion - just a simple "for testing" context manager function that allows me to not use any private vars would suffice.

If you wish, I can make a suggestion via PR next week.

[shevron]

Basically, if RawContextMiddleware was slightly refactored in:

starlette-context/starlette_context/middleware/raw_middleware.py

Lines 95 to 98 in 4550a19

	try:
	await self.app(scope, receive, send_wrapper)
	finally:
	_request_scope_context_storage.reset(token)

to use an external context manager, similar to:

@contextlib.contextmanager
def request_scope_context():
    token: Token = _request_scope_context_storage.set(context)
    try:
        yield
    finally:
        _request_scope_context_storage.reset(token)

class RawContextMiddleware:
    # ...
    async def __call__(self, scope: Scope, receive: Receive, send: Send) -> None:
        # ... line 95:
        with request_scope_context():
            await self.app(scope, receive, send_wrapper)

Then the same context manager (request_scope_context() or whatever it is named) could be used in testing as well.

[hhamana]

Internally using a similar context manager in middlewres (that part might even be shared in both ContextMiddleware and RawContextMiddleware), and exposing it some way can be a convenient approach.

Many libraries provide a pytest plugin to expose fixtures, it wouldn't be so weird. Although the common approach seems to be publishing it as a separate package, so only pytest users download it, which may be troublesome by itself.

A user testing would expect a fully operational context, able to both to set and get values (as part of the test setup, function tested or assertion), and monkeypatching might be harder to even get right, compared to just setting it the same way a middleware does.

[rosscdh]

issue importing the request_scope_context

starlette-context==0.3.3

ImportError: cannot import name 'request_cycle_context' from 'starlette_context' (/usr/local/lib/python3.9/site-packages/starlette_context/__init__.py)

[tomwojcik]

issue importing the request_scope_context

starlette-context==0.3.3

ImportError: cannot import name 'request_cycle_context' from 'starlette_context' (/usr/local/lib/python3.9/site-packages/starlette_context/__init__.py)

Hasn't been released yet. #72

[tomwojcik]

released in 0.3.4