pytest-dev
No API to request fixtures from pytest.Item
It made me a bit sad that I had to c'n'p this piece of code, rather than call a helper, to request fixtures in an Item subclass:
https://github.com/cjw296/sybil/blob/552d3ff2d6e8639ee5d3c8efa26f5e535e064ae8/sybil/integration/pytest.py#L41
That's a little clumsy I agree. Unfortunately I'm not sure we want to expose the current fixture API as official right now, given that time and time again we mention that this part of the code could use some refactoring...
@nicoddemus it helps to get an understanding of the severity of design problems if we get those that suffer them log them here ^^
I'm not complaining about @cjw296 posting the issue at all (sorry if it looked like that way), I was just replying to it. 😁
This is kind of annoying. Closing an issue because no-one has had a chance to work on it doesn't make the issue go away. @nicoddemus / @RonnyPfannschmidt - is this some new way of trying to clean up the tracker? It's not a great experience...
@Zac-HD i'm under the impression that your cleanups are more zealous than necessary
Would it be possible to re-open this issue? (I mean, unless the problem hasn't actually been fixed, in which case, if you could point me at what I need to do instead of https://github.com/cjw296/sybil/blob/master/sybil/integration/pytest.py#L42-L57)
@Zac-HD - unfortunately, the "right way" to do this is to actually look at each issue, do the digging, and see if the problem has been fixed or is no longer applicable. If that's true, then ping your findings on the ticket and close it...
...if not, by all means ask if the OP still cares, and if they don't respond within a week or two, then it's a safe bet it can be closed.
Sorry - I'm still finding the right balance for that.
No worries! I for one definitely appreciate your periodic triage of the issue tracker. We also try to find the right balance, don't worry. And we can always re-open an issue if we find that's the correct course of action.
I just ran into this issue. I want to use some functionality that's only available in fixtures (namely, capture logs) inside a test implemented as pytest.Item.runtest being generated by pytest_collect_file.
Some fallout from #11868:
- https://github.com/smarie/python-pytest-cases/issues/330
- https://github.com/simplistix/sybil/issues/107
What's the current state on:
Unfortunately I'm not sure we want to expose the current fixture API as official right now, given that time and time again we mention that this part of the code could use some refactoring...
Given that IIRC we had a lot of refactorings to fixture implementations recently? @bluetech @sadra-barikbin
the large, awesome and numerous refactorings @bluetech and @sadra-barikbin poured in over the last few months, are but the tip of the iceberg
i'm still very terrified of opening the api up, as i'm aware of a lot of the backlogs and pains ever since the 2016 sprint i wish there was more time and attention that i could pour into the topic as well - the progressions that @sadra-barikbin and @bluetech brought in are very uplifting to say the least
i'm still very terrified of opening the api up
While I share that fear, we probably don't need/should not just open the API, we can probably start small with functions/methods which are based on pytest's external design, rather than exposing implementation details.
Just an example from the top of my head, we could introduce a method to pytest.Item which returns a tree-like structure with all the fixture values active on it. This does not reflect the internal state of things, but seems like it would be stable enough regardless of changes in implementation: pytest will always have the notion of fixtures active on an item, and fixture closures.
@cjw296 Can you describe what "request fixtures from pytest.Item" means? It is not very clear. I assume it's not literally requesting a fixture, since request.getfixturevalue() exists.
@bluetech i believe it relates to the initially linked code dealing with non-python items
as far as fixture configuration, parameterization and state management is concerned, a lot of it is has so far primarily stuck on python details
as far as fixture configuration, parameterization and state management is concerned, a lot of it is has so far primarily stuck on python details
Right, I'm mostly interested to know which fixture functionality these non-python items want to use (i.e. use cases), and what they currently implement using the pytest internals.
@bluetech - ultimately, I need to do this:
class SybilItem(pytest.Item):
...
def setup(self) -> None:
for name, fixture in ...:
self.example.namespace[name] = fixture
...but to do that, I currently need to do this:
https://github.com/simplistix/sybil/blob/0fc6f9cca420d46481e0e4bf3668b40f38034abc/sybil/integration/pytest.py#L51-L70
...and then this:
https://github.com/simplistix/sybil/blob/0fc6f9cca420d46481e0e4bf3668b40f38034abc/sybil/integration/pytest.py#L84-L87
If there's a better, more supported way to do this, I would love a PR to show me how!
What is
fixturein this example?
The instance of whatever the fixture is.
For example, if this were a normal pytest function:
def test_foo(bar: Baz) -> None:
...
...then name='bar' and fixture is an instance of type Baz.
A note: while supporting basic fixtures is one thing and probably possible, supporting parametrization will be quite a bit more difficult. Even for pytest's own doctests it's broken -- the following errors out:
import pytest
@pytest.fixture(autouse=True, params=[1, 2])
def number(request, doctest_namespace):
doctest_namespace["number"] = request.param
def func():
"""
>>> number < 10
True
"""
A note: while supporting basic fixtures is one thing and probably possible, supporting parametrization will be quite a bit more difficult.
I think it is OK to only support basic fixtures initially, with an error if a parametrized fixture is requested. This will probably already cover the majority of cases.
