-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Integrate pytest-lazy-fixtures into core? #3244
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
Comments
as far as i can tell from that i can also tell is that lazy_fixtures is semantically broken due to the evaluation mechanism being foreign to the fixture mechanism (as such, dependent fixtures may get the wrong values) additionally lazy_fixtures is unaware of the potential parameterization of requested fixtures which should be noted as shortcoming as such i consider lazy_fixtures a good initial prototype one part can be solved by the new fixture setup hooks, which can be used to map from a request to the desired fixture values the other part may need a design discussion and perhaps needs to be deferred, as parametrization of the dependent fixtures needs to be taken care of either by explicit declaration of the parameter at the request or by extending collection/parametrization i propose initially bailing out if a requested fixture is parametrized, and later on deciding a more nuanced mechanism |
Thanks @RonnyPfannschmidt! In the light of the technical details highlighted by @RonnyPfannschmidt, I propose then that we work with @TvoroG to solve while documenting |
Hi! Sorry for late response :)
|
@TvoroG no, the parametrization is pretty hard to solve, and not necessarily correct that way imagine a local override of a requested parameter fixture that changes parameter counts/values or even goes from parametrized to un-parametrized what i would like to see solved is awareness of parametrization in such cases and early bail out + good errors in such cases because this one will bite hard otherwise |
@RonnyPfannschmidt I didn't quite get that, can you provide a minimal example that shows the problem (preferably using |
@fixture(params=["a", "b", "c"])
def moarfun(request):
return request.param
@fixture(params=[1,2,3])
def whops(request, moarfun):
return request.param
@pytest.mark.parametrize('a', [
lazy_fixture('whops'), # not clear how to expand
lazy_fixture_ex('whops', params=[1,2,3]), # dito
lazy_fixture_ex2('whops', param=1), # explicit expansion, still unaware of indirect things
lazy_fixture_ex2('whops', param=2),
lazy_fixture_ex2('whops', param=3),
]
def test(a):
pass |
Is anyone working on it ? |
@rajibmitra until pytest_layz_fixtures is actually up to the task merging it to the core is taking on technical debt with high interest and low payback probability - so no |
Hello, is there any progress? |
Nope |
For what it's worth a +1 for this as an integration. Not popping the hood on either, the role pytest_lazy_feature tries to fill seems to have huge benefits to the community. Seems there are lots of questions on the topic and no official solutions. |
A very old and common question is "how can I use fixtures for parametrization?" (#349). During the 2016 sprint we had a discussion which resulted in a proposal, but neither approaches proposed there were implemented into the core.
Meanwhile @TvoroG went ahead and implemented the 2nd approach in an external plugin, pytest-lazy-fixture, which seems to work well in practice.
So how about we integrate that into the core? @TvoroG, is that something you would be willing to contribute?
Alternatively we do not integrate it into the core right now, but officially declare that using
pytest-lazy-fixture
is the recommended way to go for using fixtures for parametrization (just aspytest-xdist
is the official plugin to use for distributed testing). This way we can decide later to merge (if ever) depending on user feedback. This will probably also increase the visibility of the plugin, giving us a chance of seeing the plugin in the wild.I think the latter is "zero effort/high reward" because we can just add it to the docs, close the relevant issues and let users try it out immediately; the plugin doesn't seem to be very well known at the moment, I was just asked again by a coworker this question and this motivated me to write this proposal/question.
Thoughts?
The text was updated successfully, but these errors were encountered: