Multiple use of fixture in a single test

[dysfungi]

Feature request to add the ability to use a fixture more than once in the test function arguments. Off the top of my head, appending a number to the fixture name could be a decent API. Obviously don't override existing fixtures and perhaps require the appended numbers to be ascending.

@pytest.fixture
def rand_int():
    yield random.randint(0, 100)

def test_rand_ints(rand_int0, rand_int1, rand_int2):
    # do something with 3 random integers

I can get around this by creating a fixture that generates values.

@python.fixture
def randints():
    def gen(count):
        for x in range(count):
            yield random.randint(0, 100)
    yield gen

def test_randint_gen(randints):
    r1, r2, r3 = randints(3)
    # do something with 3 random integers

I realize these examples could just be utility functions, but consider the following examples that require cleanup.

@python.fixture
def user():
    u = models.User()
    u.commit()
    yield u
    u.delete()

@python.fixture
def usergen(request):
    def gen(count):
        for x in range(count):
            u = models.User()
            u.commit()
            request.addfinalizer(lambda u=u: u.delete())
            yield u

    yield gen

def test_user(user0, user1, user2):
    # do something with 3 users

def test_usergen(usergen):
    user1, user2, user3 = usergen(3)
    # do something with 3 users

I think this deserves debate as my suggestion requires less code and I believe to be more intuitive.

It should be noted that adding scope to either solution will be confusing and probably not recommended (e.g., @fixture(scope='module')).

[RonnyPfannschmidt]

that would require fixtures to match argument names in a new way,
its hard to impossible wit the current internals and requries a rearchitecting, but i consider that worthwhile

[massich]

If the argument names matching needs to be reworked anyway, would this call be easier?

@pytest.fixture
def rand_int():
    yield random.randint(0, 100)

def test_rand_ints(r0=rand_int, r1=rand_int, r3=rand_int):
    # do something with 3 random integers

[nicoddemus]

How would we handle fixture inter-dependencies with this feature?

For example, from the original example, what happens if another fixture also depends on the user fixture?

@pytest.fixture
def subscribed_user(user):
    # subscribe user to newsletter
    return Subscription(user)

def test_user(user0, user1, user2, subscribed_user):
    ...

Which of the user0, user1, user2, is subscribed by "subscribed_user" in this test?

Also, one of the criticisms of pytest is being a little implicit with the fixture injection mechanism, so I'm not sure adding more implicitly to it would be a good idea. @massich's suggestion of using keyword arguments might be a solution to that though.

[RonnyPfannschmidt]

well - from my pov - until we rework the fixture mechanism into a externally usable library its going to be a huge disservice for any user

[dysfungi]

For example, from the original example, what happens if another fixture also depends on the user fixture?

@pytest.fixture
def subscribed_user(user):
   # subscribe user to newsletter
   return Subscription(user)

def test_user(user0, user1, user2, subscribed_user):
   ...

Which of the user0, user1, user2, is subscribed by "subscribed_user" in this test?

This is partly what sparked this proposal. Honestly, I don't like that the same fixture value is used for every instance. I realize it's a function scope, but most likely, I can access subscribed_user.user. If I specify another user in the test case, then I want it to be different. Actually, I assumed user would be different when I first tried it.

@pytest.fixture
def test_user(user, subscribed_user):
    assert user != subscribed_user.user  # I want this to succeed

Perhaps another scope such as @pytest.fixture(scope='unique')?

I very much like @massich's keyword argument suggestion.

[RonnyPfannschmidt]

we tried to introduce such scopes, but it was demonstrate that this currently breaks the world - internal refactorings are needed

[nicoddemus]

Honestly, I don't like that the same fixture value is used for every instance.

I see @Defrank, thanks. I've seen people on occasion with the same impression, but I think the current system is more powerful because reusing fixture instances within the same context is what allows you to actually create more complex systems.

For example, consider the tmpdir fixture; if a different instance was created for each fixture involved in a test function invocation, its usefulness would be severely limited.

By the way, a simple way to obtain the functionality you need is to make your fixture a factory instead; that gives you full control when and where to create the instances.

def test_user(user_factory):
    user0, user1 = user_factory.create('calvin', 'hobbes')

For convenience, you might also have a user fixture which creates a default user:

@pytest.fixture
def user(user_factory):
    return user_factory.create('jonh')

Pytest itself follows the same approach with the tmpdir_factory fixture.

[dysfungi]

Yeah, the usergen was my factory solution. What about some sort of @pytest.factory fixture that could be special-cased for these uses?

[nicoddemus]

What about some sort of @pytest.factory fixture that could be special-cased for these uses?

Hmm how would that work? Could you provide an usage example?

[nicoddemus]

Yeah, the usergen was my factory solution.

Oh I must have forgotten about it, sorry about that.

[dysfungi]

What about some sort of @pytest.factory fixture that could be special-cased for these uses?

Hmm how would that work? Could you provide an usage example?

Factory

Essentially, mark factory fixtures.

@pytest.factory
def user_factory(request):
    def factory(*names):
        for name in names:
            user = models.User(name=name)
            user.commit()
            request.addfinalizer(lambda u=user: u.delete())
            yield user

    yield factory

Idea 1

@pytest.fixture
def user(bob=user_factory):
    yield bob


def test_user_factory(user, amy=user_factory, Joe=user_factory):
    assert user.name == 'bob'
    assert amy.name == 'amy'
    assert Joe.name == 'joe'

I don't like this:

1. Restricts keys to be alphanumeric and valid variable names
2. Mixing case for keys like Joe is against PEP8
3. user_factory as the default argument will break linters if user_factory isn't in scope

Idea 2

Require factory from user_factory be replaced with unique identifier.

@pytest.fixture
def user(user_0='bob'):
    yield user_0


def test_user_factory(user, user_1='joe', user_amy='amy'):
    assert user.name == 'bob'
    assert user_1.name == 'joe'
    assert user_amy.name == 'amy'

Since my factory requires names, I'm not considering the following, although it should be considered:

def test_user_factory(user, user_amy, user_john):
    assert user != user_amy
    assert user != user_john
    assert user_amy != user_john

[RonnyPfannschmidt]

imho we need a mechanism that handles a mapping of parameter names and fixtures/parameter sets

all proposals i have seen here so far cant even hope to fit the bill