getsentry / pytest-responses

py.test integration for responses

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Separate responses startup/teardown from fixture

jaraco opened this issue · comments

I'd like to use pytest_responses, but I don't like that simply including pytest_responses in the test suite enables responses for all my tests.

Although pytest_responses does provide a way to opt out of this behavior, I think it would be better to allow a project to opt in to this behavior, such that including pytest_responses in the test environment has no default effect.

And instead, make the implicit startup/teardown explicit. e.g.:

@pytest.fixture
def all_responses(request):
    if request.get_marker('withoutresponses'):
        return
    responses._start()
    yield
    # patcher was already uninstalled...
    with contextlib.suppress(RuntimeError):
        responses._stop()
        responses._reset()

instead of the pytest_runtest_* functions.

Then, a project that wishes to have this behavior could:

pytestmark = pytest.mark.usefixtures('all_responses')

In whichever scope they wish to enable responses (or in conftest.py for the global scope).

Right now, as implemented, it's not possible to get the responses fixture without also getting the all_responses behavior.

I haven't tested the above proposed technique, so there may be some issues that need to be resolved around it, but I was hoping to get some feedback on the concept, or learn if maybe there's something I'm missing that would otherwise alleviate my concern.

I am running into this as well and it is a major blocker in utilizing pytest-responses

Likewise.
I've created distro package https://build.opensuse.org/package/show/home:jayvdb:py-new/python-pytest-responses but this really shouldnt be distributed as a distro package because merely installing it at the system level would break any other use of pytest which uses requests but isnt using pytest-responses, which is a very large cohort. That needs a huge warning before installation.