Suggestion: add new 'parametrization' fixture scope

[csaftoiu]

Currently, a fixture can be scoped as function, class, module, or session.

I propose a fixture can also be scoped per parametrization.

Consider:

import time
@pytest.fixture
def slow_setup():
    time.sleep(1)
    return 'foo'

If I have a group of tests which I am parametrizing, but that would share this value, it'll do the setup for each one (as expected):

# takes 4 seconds
@pytest.mark.parametrize('bar', [1, 2, 3, 4])
def test_parametrized(slow_setup, bar):
    assert slow_setup == 'foo'

If I wanted to run the same group of tests but sharing the fixture, I only really have one option (considering that other tests in the same module need the fixture to be re-set up each time, so I can't use module or session scope): set the fixture scope to class, and put the tests inside a class:

@pytest.fixture(scope='class')
def slow_setup_cls():
    time.sleep(1)
    return 'foo'

# takes 1 second
class TestParametrized(object):
    @pytest.mark.parametrize('bar', [1, 2, 3, 4])
    def test_parametrized(self, slow_setup_cls, bar):
        assert slow_setup_cls == 'foo'

However, the meaning I really intend to convey is "this fixture should be shared across all parametrizations of a function". I propose the following:

@pytest.fixture(scope='parametrization')
def slow_setup_pmt():
    time.sleep(1)
    return 'foo'

# takes 1 second
@pytest.mark.parametrize('bar', [1, 2, 3, 4])
def test_parametrized(self, slow_setup_pmt, bar):
    assert slow_setup_pmt == 'foo'

This fixture scope conveys, to me: "All parametrizations of this test share the same setup and teardown with regards to this fixture."

[RonnyPfannschmidt]

i like the idea

currently the proposal has 2 semantical problems

1. there is no collection element for the function that is not parameterized (scoping selects the collection tree element based on a type belonging to the
2. parameterization can happen on more than one scope ( class/module/session scoped fixtures may be parameterized as well

[SalmonMode]

Why not just have parametrized fixtures that have autouse as True (factoring in dependencies, of course) make multiple versions of the scopes they are designated for?

For example, currently, given the following module:

import pytest


@pytest.fixture(scope="class", autouse=True)
def before_param():
    print("in before_param")


class TestIt():

    @pytest.fixture(scope="class", autouse=True, params=["a", "b"])
    def param_fix(self, before_param, request):
        print("in param_fix")
        return request.param

    @pytest.fixture(scope="class", autouse=True)
    def other_fix(self, param_fix):
        print("in other_fix")

    def test_stuff(self, other_fix):
        assert True

You get the following flow:

test_module (module)
└── TestIt (class)
    └── before_param
        ├── param_fix["a"]
        |   └── other_fix
        |       └── test_stuff (function)
        └── param_fix["b"]
            └── other_fix
                └── test_stuff (function)

But since autouse is True, the whole of that scope should be impacted. That, to me, would mean that I want to go through that scope, in it's entirety, once for each param set, as each set should impact the whole scope on its own. Here's the flow I would expect in this case:

test_module (module)
├── TestIt["a"] (class)
|   └── before_param
|       └── param_fix
|           └── other_fix
|               └── test_stuff (function)
└── TestIt["b"] (class)
    └── before_param
        └── param_fix
            └── other_fix
                └── test_stuff (function)

In this case, param_fix made two versions of the TestIt class, one for each param set.

If autouse is not True, then just only make multiple versions of the individual tests that depend on it.

This covers @csaftoiu's example with pytest.mark.parametrize without adding a need to use another argument or alternate scope options.

[SalmonMode]

So after doing some digging into pytest, it looks like my initial idea of having multiple versions of each scope would pretty much require a total rework of test collection/execution. But I did find what I think is a good place to make a small change so that autouse parametrized fixtures cause other fixtures for that scope to re-execute as well.

I'm writing up a pull request now to put in this change. If it's decided to not go this route, and instead add a new argument/scope to trigger this kind of behavior, I think the changes I've made so far can be easily modified to do that instead.

[toby-w]

i like the idea

currently the proposal has 2 semantical problems

1. there is no collection element for the function that is not parameterized (scoping selects the collection tree element based on a type belonging to the
2. parameterization can happen on more than one scope ( class/module/session scoped fixtures may be parameterized as well

Hi @RonnyPfannschmidt, I am not clear on the two semantical issues that adding a parametrization scope would raise. Could you provide an example of how this would be a problem?