Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide dependency-tested autouse fixtures #1050

Open
RonnyPfannschmidt opened this issue Sep 22, 2015 · 7 comments
Open

provide dependency-tested autouse fixtures #1050

RonnyPfannschmidt opened this issue Sep 22, 2015 · 7 comments
Labels
topic: fixtures anything involving fixtures directly or indirectly type: enhancement new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@RonnyPfannschmidt
Copy link
Member

autouse fixures should have a mode of operation that triggers them only if the fixtures they need are used by the current test to begin with

@nicoddemus
Copy link
Member

Could you clarify a bit @RonnyPfannschmidt? Perhaps with an example.

@hpk42
Copy link
Contributor

hpk42 commented Sep 22, 2015

i have a vague idea what you mean but would like to see a clearer problem statement and an example as well.

@RonnyPfannschmidt RonnyPfannschmidt added type: enhancement new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature labels Sep 23, 2015
@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus @hpk42

import pytest

@pytest.fixture
def fun():
  pass


@pytest.fixture(autouse='if_dependencies_met')
def no_fun(fun):
  raise ValueError(42)

def test_1(fun):
  pass


def test_2():
  pass

should allow py.test -k test_2 to pass fine
a better name may be needed

@hpk42
Copy link
Contributor

hpk42 commented Jan 18, 2017

is 'if_dependencies_met' a concrete example? Some kind of a special value that leads to test_2 not receiving no_fun because fun is not used by test_2?

From a usability side it might be better to explicitly list "triggering" fixtures like in the above case autouse_if='fun'.

Implementation wise i guess it's not easy to implement but not sure.

@RonnyPfannschmidt
Copy link
Member Author

Correc, just a initial example

@seifertm
Copy link

I'd like to share a use case for this functionality. The pytest-asyncio plugin allows users to use coroutines and async generators for tests and fixtures as illustrated in the following example:

async def test_my_coro():
    ...


@pytest.fixture
async def test_my_fixture():
    ...

Pytest-asyncio also exposes the current asyncio event loop via an event_loop fixture. The fixture dependency is injected as a dependency into async tests and async fixtures. While it may be possible to simply enable autouse=True for the event_loop fixture to make it available enable to all tests and fixtures, this may potentially break existing tests. Crucially, this can break these tests just by installing pytest-asyncio.

What I'd like to do is something like:

def is_asyncio_test_or_fixture():
    ...

@pytest.fixture(autouse=is_asyncio_test_or_fixture)
def event_loop():
    ...

Pytest-asyncio currently tries to emulate this behaviour by tapping into FixtureManager. It uses FixtureManager._arg2fixturedefs and adds request and event_loop to fixturenames of applicable FixtureDefs. However, this implementation uses a non-public pytest API, requires quite deep understanding of pytest internals, and—most of all—causes issues. This is why I'm looking to replace it.

Do you think this a valid use case for this feature?

@RonnyPfannschmidt
Copy link
Member Author

It's not a direct match, however we currently also have no sane way to attach a fixture only to specific tests

For event loop control it may be a good idea to make a hook wrapper for the test protocol hooks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: fixtures anything involving fixtures directly or indirectly type: enhancement new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

5 participants