-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Suggestion: add new 'parametrization' fixture scope #1552
Comments
i like the idea currently the proposal has 2 semantical problems
|
Why not just have parametrized fixtures that have 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:
But since
In this case, If This covers @csaftoiu's example with |
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. |
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? |
what should be the order of tests and the setup/teardown in that case |
If I understand it correctly, it means that in terms of levels, it should be Then the example would not be valid @RonnyPfannschmidt , as -- Actually the In fact I think it would be more accurately defined as:
|
@toby-w @Sup3rGeo I think what @RonnyPfannschmidt is referring to, is the fact that you can apply a parametrization within multiple scopes (i.e. session/package/module/class/function), and having a "param" scope doesn't specify which level of parametrization you would want to target. For example:
The question is what level of parametrization are you targeting with I also don't think @csaftoiu's proposal would actually solve the problem, because a scope of "param"/"parametrization" would suggest that it happens for each parameter set, meaning it would still run the slow running fixture more than once. Granted, the "param" (or whatever it would be called) scope of that type could be used to go back to the current behavior, while the standard "function" level could be made to operate like the larger scopes. But that would likely break a lot of previously written tests, so it's a lose-lose situation. |
@SalmonMode yep, so what I wrote was my understanding of the feature @csaftoiu described in this issue, which I am convinced is different from what @RonnyPfannschmidt understood. As I understand, the OP wants to have this:
With only two fixture invocations:
Currently, if the Thats why he uses the workaround of having classes:
Then we get the desired two invocation scenario. |
Currently, a fixture can be scoped as function, class, module, or session.
I propose a fixture can also be scoped per parametrization.
Consider:
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):
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:
However, the meaning I really intend to convey is "this fixture should be shared across all parametrizations of a function". I propose the following:
This fixture scope conveys, to me: "All parametrizations of this test share the same setup and teardown with regards to this fixture."
The text was updated successfully, but these errors were encountered: