Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Move
fixtures.py::add_funcarg_pseudo_fixture_def
toMetafunc.parametrize
#11220Move
fixtures.py::add_funcarg_pseudo_fixture_def
toMetafunc.parametrize
#11220Changes from 1 commit
96be57a
40b2c09
8b59725
2853331
c7f4f91
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be helpful for clarity if (in separate PR) we change
_resolve_arg_value_types
like so:_resolve_arg_directness
- "arg value type" is pretty generic/non-specific and doesn't say much.Literal['params', 'funcargs']
toLiteral['direct', 'indirect']
.Then the check becomes
if arg_directness[argname] == "direct": continue
which is pretty self-explanatory I think.Note: we can do it later, you don't have to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this particular usage indicates to me that we may want to investigate having a "constant" definitions that could be used to represent params both from parametrize, and also declaring fixtures that repressent sets of values
details are for a followup that may want to also integrate pytest-lazyfixtures
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By "constant" you mean stateless? A fixturedef that just returns its input?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exact
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now
params=None
, where before it wasparams=valuelist
. This made me confused somewhat.My mental model for before was the basically desugar this:
to this:
but with
params=None
that makes less sense now. And indeed, if we change toparams=None
in the current code, all tests still pass, i.e. it wasn't needed even before.I guess then that the correct mental model for the desugaring is indirect parametrization of the
x
fixture? I.e. this:Ran out of time to look into it today but will appreciate your insights :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. It is the test that holds param values in its callspec and the fixtures that it depends on, use them at test execution time. The only usage of
fixturedef.params
is infixtures.py::pytest_generate_tests
that the directly parametrized fixture hand the params to the test that uses it. By directly parametrized fixture, I mean this:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said in https://github.com/pytest-dev/pytest/pull/11231/files#r1278270549 IMO this change makes sense (though @RonnyPfannschmidt may still disagree).
But I would like to understand what exactly in this PR is causing this change? @sadra-barikbin do you think you can explain it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i left another comment, i think we can choose to opt for the new ordering if we ensure to add the tools i mentioned there eventually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current ordering stems from the way
add_funcarg_pseudo_fixture_def
assigns index to params. It assignsi
to the index ofall
of the params ini
th callspec of the metafunc. In our example,test_one
andtest_two
, each have 4 callspecs and two params (arg1
andarg2
). We assign index 0 toarg1
andarg2
oftest_one[arg1v1,arg2v1]
and also to those oftest_two[arg1v1,arg2v1]
. We assign index 1 toarg1
andarg2
oftest_one[arg1v1,arg2v2]
and also to those oftest_two[arg1v1,arg2v2]
and so on. As a result,i
th callspecs of the two metafuncs would have common fixture keys. In our example,k
thtest_one
pullsk
thtest_two
towards itself, so we would have a one-two-one-two... pattern. Alsotest_one
(alsotest_two
ones) items would have no common fixture key because their index ofarg1
andarg2
is 0,1,2 and 3.The new way assigns
i
to the index of paramj
in all callspecs that usei
th value ofj
. So the decision is made on a per-param basis. In our example, we would assign index 0 toarg1
of the items that usearg1v1
and index 1 toarg1
of the items that usearg1v2
and so on. As a result, if two callspecs have thei
th value of the paramj
, they have a common fixture key.The new way is improved in determining what
i
th value of the param is when there are multiple parametersets in #11257 .There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reading your comment and looking more closely at the issue_519.py file, I think I understood some things:
First, I'm really not used to the
pytest_generate_tests
hook, so I rewrote the test usingpytest.mark.parametrize
. I also changed some of the names to make things clearer to me:Rewritten issue_519.py
This made me realize that the apparent niceness of the previous ordering, which orders
test_one[arg1v1-arg2v1]
next totest_two[arg1v1-arg2v1]
, thus saving a setup, is pretty arbitrary. This can be shown by making the values of the function-scoped parameter (arg2
/b
) different intest_one
andtest_two
:The ordering stays the same, which now doesn't make sense.
I also figured that the entire
param_index
thing was much more useful/natural in the pre-parametrize
times, when onlypytest_generate_tests
/metafunc
was used for parametrizing. Withpytest_generate_tests
you often use the same parameter set for different tests, as is done in the issue_519.py file. But withparametrize
, which is mostly done for a single test-function only, it is much less common, I think.