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

LazyFixture only resolved when used directly, but not in lists etc. #24

Open
cb109 opened this issue Mar 7, 2018 · 7 comments
Open

Comments

@cb109
Copy link

cb109 commented Mar 7, 2018

My use case requires preparing lists of things instead of just single things one by one, please see your example adapted accordingly below.

import pytest

@pytest.fixture(params=[
    [pytest.lazy_fixture('one')],
    [pytest.lazy_fixture('one'), pytest.lazy_fixture('two')],
])
def some_list(request):
    return request.param

@pytest.fixture
def one():
    return 1

@pytest.fixture
def two():
    return 2

def test_func(some_list):
    from pprint import pprint
    pprint(some_list)
    assert 1 in some_list

Inside test_func() the some_list will be something like [<LazyFixture "one">, <LazyFixture "two">] where I would have expected that this had been expanded/resolved to [1, 2].

Is there a way to always expand /resolve in a test context no matter how wrapped or nested the LazyFixture is?

Cheers

@TvoroG
Copy link
Owner

TvoroG commented Mar 12, 2018

Hi, @cb109! For now it's not possible to expand lazy fixture inside of nested objects. Here is a similar issue.

I will not close it, because it's an issue anyway. Thanks!

@muvster
Copy link

muvster commented Oct 8, 2018

I'd love to see this supported as well. We have a case where we want to add some metadata about existing fixtures when they are used as part of a different fixture. The metadata doesn't make sense to include in the original fixtures because it is only relevant in the new context. The natural way to tie the original fixtures and related metadata together would be in the params of the new fixture.

@gimbo
Copy link

gimbo commented Apr 23, 2020

Another place where this shows up is parametrized tests which operate over arbitrary numbers of arguments, which is something I often use.

Toy example:

@pytest.mark.parametrize(
    'args',
    (
        (),
        (None, None, None),
        (lazy_fixture('some_fixture'), 12.5, 'foo', ['hello world']),
    ),
)
def test_with_arbitrary_list_of_args(args):
    # Do something with args here...

Here on the third run of the test, args[0] will be <LazyFixture "some_fixture"> rather than the result of that fixture; to get the actual result I am forced to use a fixed number of explicitly-named arguments, it seems.

@blaise17
Copy link

I also have this issue. My use case is a single test that checks that all the methods that should raise a certain exception do, so in my parametrize I pass in the Callable as one argument and the "extra parameters" dictionary as the second. I then expand this to pass them in as keyword args to the Callable, but one of these extra parameters, for one method only, needs to use a fixture (as the exception is only thrown when all other params are valid).

@z33kz33k
Copy link

Count me also among those who consider this issue important.

@KerH
Copy link

KerH commented May 11, 2022

I tackled it as well, in my case I wanted to pass a dictionary with multiple fixtures. Since it was passed as a sequence I don't have the access to the fixture value within. +1 for this request.

@codectl
Copy link

codectl commented Aug 8, 2022

This feature would be useful. But since there is no plans to release this, I am moving to pytest-cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants