Using fixtures in pytest.mark.parametrize

Originally reported by: Florian Rathgeber (BitBucket: frathgeber, GitHub: frathgeber)

I often have a use case like the following contrived example:

@pytest.fixture
def a():
    return 'a'

@pytest.fixture
def b():
    return 'b'

@pytest.mark.parametrize('arg', [a, b])
def test_foo(arg):
    assert len(arg) == 1

This doesn't currently do what's intended i.e. arg inside the test function is not the fixture value but the fixture function.

I can work around it by introducing a "meta fixture", but that's rather ugly:

@pytest.fixture(params=['a', 'b'])
def arg(request, a, b):
    return {'a': a, 'b': b}[request.param]

def test_foo(arg):
    assert len(arg) == 1

It would be convenient if a syntax like in the first case was supported.

Bitbucket: https://bitbucket.org/pytest-dev/pytest/issue/349

Original comment by Matthias Geier (BitBucket: geier, GitHub: geier):

This would be a great feature!

I found another (I don't know if more or less ugly) work-around:

#!python

@pytest.mark.parametrize('arg', ['a', 'b'])
def test_foo(arg, request):
    val = request.getfuncargvalue(arg)
    assert len(val) == 1

This doesn't work, however, with parametrized fixtures.

BTW, it would also be great if fixtures were supported in the params argument of pytest.fixture.

Original comment by Floris Bruynooghe (BitBucket: flub, GitHub: flub):

Tentatively assigning this to me as I think I might be able to come up with a reasonable patch. It'll probably take me a long while though so don't let that discourage anyone else from working on this, assigning it more as a way of not forgetting about it.

Original comment by Praveen Shirali (BitBucket: praveenshirali, GitHub: praveenshirali):

The quoted examples work because functions a and b are part of the same module as test_foo, and within the scope of the example, the parametrization should work even if @pytest.fixture decorator isn't present around functions a and b. They are getting used as regular python functions and not as pytest fixtures. Note that fixtures can also be defined in external modules like conftest.py.

Another alternative to the above example is to directly call these functions in the list.

#!python

@pytest.mark.parametrize('arg', [a(), b()])
def test_foo(arg):
    assert len(arg) == 1

@praveenshirali

Original comment by BitBucket: dpwrussell, GitHub: dpwrussell:

This would be an awesome feature.

@praveenshirali I don't think your alternative is used as a fixture, it just calls the fixture function. So it would be run repeatedly. You would also have to specify the arguments to the fixture if there were any which could begin the cycle over again if they are also fixtures.

Here's a related stackoverflow question: http://stackoverflow.com/questions/24340681/how-to-concatenate-several-parametrized-fixtures-into-a-new-fixture-in-py-test

Yes, I would like very much to have this feature also. Maybe a line in the doc explaining it's not possible for the moment would be useful also.

It would also be killer if this supported parameterized fixtures generating the product of the fixtures. Although this might be a little much.

@pytest.fixture(params=["1", " ", 1, True, [None], {1:2}])
def truthy(request):
    return request.param

@pytest.fixture(params=[False, None, "", 0, [], {}])
def falsey(request):
    return request.param

@pytest.mark.parameterize("val,res", [
    (truthy, True),
    (falsey, False),
])
def test_bool(val, res)
    assert bool(val) is res

+1 for this feature.
BTW, combining Florian Rathgeber and Matthias Geier solutions we can get a bit nicer "meta fixture":

@pytest.fixture
def a():
    return 'a'

@pytest.fixture
def b():
    return 'b'

@pytest.fixture(params=['a', 'b'])
def arg(request):
    return request.getfuncargvalue(request.param)

def test_foo(arg):
    assert len(arg) == 1

+1 on this.

I'm currently writing tests that look like:

@pytest.fixture
def my_fixture():
      return 'something'

@pytest.fixture
def another_fixture(my_fixture):
      return {'my_key': my_fixture}

def yet_another_fixture():
     return {'my_key': None}

@pytest.mark.parametrize('arg1, arg2', [
    (5, another_fixture(my_fixture())),
    (5, yet_another_fixture()),
)
def my_test(arg1, arg2):
    assert function_under_test(arg2) == arg1

and that's rather ugly.

@rabbbit

@rabbbit your example is structurally wrong and runs fixture code at test importation time

@RonnyPfannschmidt

@RonnyPfannschmidt I know - and that's why I'd like to be able to use fixtures in parametrize? And that would be awesome.

My example is wrong, but it follows the guideline of "always use fixtures". Otherwise we'd end up with fixtures in normal tests, and workarounds in parametrized tests.

Or is there a way of achieving this already, outside of dropping parametrize and doing 'if/elses' in the test function?

There is a upcoming proposal wrt "merged" fixtures, there is no implementation yet

For reference: #1660

Just a quick note to say the pytest-lazy-fixture package mentioned as a workaround here appears to be dead, with many unaddressed open issues and it's not compatible with pytest>=8.0.0. This would be a nice quality of life feature to have natively in pytest.

@chrisk314

@chrisk314 You can use pytest-cases as a workaround (https://smarie.github.io/python-pytest-cases), it is alive and kicking :) (and compliant with pytest 8 since version 3.8.3)
See #349 (comment)

Still, I agree with you that it would be better to refactor the internal engine to handle all of this in pytest. This would require massive rework unfortunately... which is why the team did not do it yet.

Any news on that? That would be and great feature... and installing more and more libs to handle those kind of cases it is not the best answer :)

If there were any news, it would be here in the issue. That's kind of the whole point of a public issue tracker.

https://github.com/dev-petrov/pytest-lazy-fixtures

https://github.com/dev-petrov/pytest-lazy-fixtures

That cannot be the "only answer" to the problem...

If there were any news, it would be here in the issue. That's kind of the whole point of a public issue tracker.

TBH if there is an issue that is open for 12+years I feel like there is no hope for it and it will never be implemented due to beeing in some kind of "backlog hell". Last time there was some bump here it was 9 months ago, and having that would resolve huge amount of "edge" cases in testing.
If I am wrong, deep down it would be nice to be..., and there is a chance for introducing that keep it alive. If there is no option for that "because of reasons" it should be closed with proper comment.

By chance am subscribed to this issue although i am not maintaining pytest for many years now (but using it still :). Not sure how much it's helpful, but here are my 2cents. Parametrizing a test function requires all values flowing into the test function to be known at test-collection time IIRC. Using `request.getfixturevalue()` already kind of breaks this constraint. Runtime-requested fixtures can not easily be parametrized themselves, unless something has changed in the code since i contributed it. Parametrizing a test function with fixtures (in whatever syntax) would probably need to add all parametrizations of those fixtures ... but in a kind of closure across all the different fixtures? Anyway, maybe the reason why this issue hasn't progressed is that it requires some careful thinking and design and equally careful implementation work. Just because a "rough example" is written down, does not imply that it's equally easy to actually implement it.

implementation is really tricky actually - external implementation currently break down the moment one of the fixtures we depend on is actually parameterized

parameterize would have to act like a fixpoint function to resolve that - and currently most of the internals don't support that

so right now are unable to internally express whats needed for correct resolution

implementation is really tricky actually

I confirm that ! I had to hack quite a lot to make it work nicely in all situations in a plugin (in pytest-cases). Some of the reasons disclosing the complexity behind this simple need are illustrated here : https://smarie.github.io/python-pytest-cases/unions_theory/

The problem is that a fixture is valid for an entire function scope, while a parameter is one item in the callspec of that function. So I had to "cheat" by creating a new mechanism named "fixture union" to have a fixture only used for some items of the callspec (the parameters that you want). But that "cheating" was quite hard to get right, I had to replace the whole fixture closure by a tree behaving like a list when it is looked at by pytest ; and I had afterthoughts a few months/years after, about other ways to do this (smarie/python-pytest-cases#170 (comment) )

I had to create hundreds of corner/edge-case tests to be sure to cover all situations... so far it seems to have worked pretty well as it has been used for many years with a very limited number of issues, all fixed quickly - but it is clearly not as durable/maintainable in time as it would if the feature was part of pytest. I myself now have a hard time to understand my own ugly hacky code :D . And we do not have that many contributors in pytest-cases - just a few have contributed (huge thanks to them !)

Fix certbot tests after updating pytest to 9.0.2 (#10545)

Navigation Menu

Repository navigation

Using fixtures in pytest.mark.parametrize #349

107 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Using fixtures in pytest.mark.parametrize #349

Description

Activity

pytestbot commented on Jun 21, 2014

pytestbot commented on Jun 25, 2014

pytestbot commented on Aug 3, 2014

pytestbot commented on Sep 9, 2014

mgeier commented on Jun 16, 2015

jlmenut commented on Nov 19, 2015

kevincox commented on Feb 19, 2016

SUNx2YCH commented on Feb 26, 2016

rabbbit commented on Jul 4, 2016

RonnyPfannschmidt commented on Jul 5, 2016

rabbbit commented on Jul 5, 2016

RonnyPfannschmidt commented on Jul 5, 2016

nicoddemus commented on Jul 5, 2016

107 remaining items

RonnyPfannschmidt commented on Aug 8, 2022

Lewiscowles1986 commented on Aug 8, 2022

chrisk314 commented on Apr 19, 2024

smarie commented on Jul 12, 2024

MRGuziX commented on Mar 26, 2025

The-Compiler commented on Mar 26, 2025

thetic commented on Mar 28, 2025

kielpins commented on Apr 1, 2025

MRGuziX commented on Apr 1, 2025

hpk42 commented on Apr 3, 2025

RonnyPfannschmidt commented on Apr 3, 2025

smarie commented on May 9, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions