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

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

Open
Hawk777 opened this issue Apr 3, 2025 · 2 comments

Comments

@Hawk777
Copy link
Contributor

Hawk777 commented Apr 3, 2025

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
Copy link
Member

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
Copy link
Contributor Author

Hawk777 commented Apr 4, 2025

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.

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

2 participants