-
-
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
Customize the fixture ordering on the same scope level #3393
Comments
GitMate.io thinks possibly related issues are #538 (Fixture scope documentation), #805 (Fixture execution order ), #668 (autouse fixtures break scope rules), and #2846 (Unexpected order of tests using parameterized fixtures). |
@gavincyi thanks for opening up this issue. 👍 Seems doable, although I'm not sure adding a parameter to |
cc @ceridwen and @cheezman34 because of #3161. |
I may be thinking about this wrong, but wouldn't this also be useful for non-session fixtures? In my case what I'm trying is different function scoped fixtures (e.g. I thought that the parameter order might help determine the fixture order, but that's only the case when I try a simple example like this: import pytest
@pytest.fixture
def fix_main():
pass
@pytest.fixture
def fix_pre():
pass
def test_abc(fix_pre, fix_main):
pass In my real test suite, |
Wow it took me a while but I finally found other people with the same problem as I am having now! Definitely not all fixtures for a same scope have equal weight.
I think this is valid for all the scopes higher than function - then the priority would select which fixtures should be preserved among all other fixtures at the same scope level. Is there any workarounds that can be implemented locally to overcome this problem? I thought about implementing my own algorithm in |
So my proposal would be as follows:
|
One workaround, if you have access to the code of the fixtures, is to make one fixture depend on the other. For example: @pytest.fixture
def foo():
...
@pytest.fixture
def bar():
... If you want to make sure that @pytest.fixture
def foo(bar):
...
@pytest.fixture
def bar():
... About the original proposal, I'm still not entirely sure if we should really add a |
I have a working implementation of the sorting algorithm that takes weights/priorities into account, now I just need to figure the best way to define it in tests so that the algorithm can retrieve the weights for each parameter. @nicoddemus you mentioned the idea of
How could I access that mark? I basically want to access that mark in this function (or, to be more precise, my plugin's own implementation of that): pytest/src/_pytest/fixtures.py Lines 182 to 205 in 6663cb0
And I see we could access the FixtureDef through cs.metafunc._args2fixturedefs[argname] |
People interested in this, I made a plugin that implements a Check how to use it in https://github.com/Sup3rGeo/pytest-param-priority and please provide feedback :) I did not test with classes yet. The implementation possibly can be improved, and it would be quite easier if we could just add it to FixtureDefs somehow directly (check https://github.com/Sup3rGeo/pytest-param-priority/blob/master/pytest_param_priority.py) |
Two comments on this:
|
After so many years, this question remains relevant.
Your solution seems interesting to me. It's amazing that after all this time it still causes problems |
Could we have one more parameter, e.g. priority (between 0 and 100), for the users the customize the cost of setup/teardown fixture? For example,
should give
pytest now assumes an equal weighted cost of setup/teardown fixtures. So it reorders the product of fixture combination to optimize the count of setup/teardown time. For the code given before, the current behavior is
The assumption is not pragmatic when
This enhancement will allow the users to customize the ordering if they want and resolve #2846.
The text was updated successfully, but these errors were encountered: