Documenting usability of parameter from pytest_generate_tests or pytest.mark.parametrize inside pytest.mark.usefixtures

[Hawk777]

From reading various bug reports, and especially looking at GH-11416 which I think (though am not certain) implemented some of this, I think it is intended that you be able to name a parameter provided by pytest_generate_tests or @pytest.mark.parametrize in @pytest.mark.usefixtures if you don’t actually need its value (and it certainly seems to work in practice). However, as far as I can tell, this is not actually documented.

https://docs.pytest.org/en/latest/how-to/parametrize.html doesn’t explicitly state that parameters from those two sources are fixtures (in the case of pytest_generate_tests it does tangentially refer to the parameter as “stringinput fixture function argument”, but I’d hardly call that definitive; in case of @pytest.mark.parametrize AFAICT it doesn’t mention it at all; and at the top of that page, @pytest.mark.parametrize is explained as “allows one to define multiple sets of arguments and fixtures at the test function or class.” which IMO suggests that arguments and fixtures are not the same thing).

https://docs.pytest.org/en/latest/reference/reference.html#pytest-mark-parametrize doesn’t say anything at all, just delegating to Metafunc.parametrize.

https://docs.pytest.org/en/latest/reference/reference.html#pytest.Metafunc.parametrize seems as if it’s written to very carefully avoid using the word “fixture” anywhere, except in the indirect case.

Neither https://docs.pytest.org/en/latest/reference/reference.html#pytest-mark-usefixtures nor https://docs.pytest.org/en/latest/how-to/fixtures.html#usefixtures mention @pytest.mark.usefixtures being usable for parameters that are “not fixtures”, if such a concept actually exists.

If this is meant to work, IMO it would be good to document it more clearly. I could try to write something up and make a PR, if you have an idea of where it should go (or if you think there should be a larger rewrite).

To be clear, I am talking about this:

@pytest.mark.parametrize("iteration", [1, 2, 3])
@pytest.mark.usefixtures("iteration")
def test_thingy():
    # I want this test to run three times but I don’t need to know which run this is.

I am not talking about this, which is the subject of most of the other “parametrize and usefixtures” tickets and discussion on here:

@pytest.mark.parametrize("iteration", [pytest.param(1, marks=pytest.mark.usefixtures("somefixture")), 2])
def test_thingy():
    # I want to run this twice, and I want the first run to use “somefixture”.

[The-Compiler]

IMHO the fact that parametrized arguments are (pseudo-)fixtures internally is an implementation detail and thus this just happens to work by accident. pytest-repeat seems like a much cleaner solution for what you're after.

Loosely related: #11295

[Hawk777]

Not sure I agree that using an external plugin is much cleaner than using a built-in feature. pytest.mark.repeat also wouldn’t help if I want to collect the same test with different markers, but I don’t need a parametrization value in the body. Finally, it also appears to conflict with --count in the sense that --count would either override or be ignored by pytest.mark.repeat rather than multiplying with it (which may be what I want in some cases), though admittedly the README is a little unclear on that point.

[samamorgan]

I, for one, would advocate for this being a documented, supported, and tested feature of pytest. I've been wanting exactly this functionality out of pytest for quite some time.

[RonnyPfannschmidt]

no - this ought not to be a feature - mashing together 2 marks to generate a repeat-alike without fixture usage is in very bad teste

there should be a proposal for a nice api doe tihs from people with the need

@The-Compiler i propose closing this one as wont fix - i consider the original ask of making the accident a official feature unreasonable

[samamorgan]

Yeah, I misunderstood the premise. I was thinking I could define a few fixture functions, then pass the names of those fixture functions as parametrized values to usefixtures, but that does not work (sure wish it did):

@pytest.fixture
def one() -> int:
    return 1

@pytest.fixture
def two() -> int:
    return 2

@pytest.fixture
def result(fixture: int) -> int:
    return fixture

@pytest.mark.parametrize(("fixture", "expectation"), [("one", 1), ("two", 2)])
@pytest.mark.usefixtures("fixture")
def test_contrived_example(result: int, expectation: int) -> None:
    assert result == expectation

Results in AssertionError: assert 'one' == 1

[The-Compiler]

@samamorgan You might be looking for #349 there.

@RonnyPfannschmidt I agree there isn't really anything actionable here for pytest.