No API to request fixtures from pytest.Item

[cjw296]

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

[nicoddemus]

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]

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.

[oprypin]

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.

[The-Compiler]

Some fallout from #11868:

• @fixture incompatible with pytest 8.0.0 smarie/python-pytest-cases#330
• Pytest 8 error: FixtureManager.getfixtureclosure() missing 1 required positional argument: 'ignore_args' simplistix/sybil#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

[RonnyPfannschmidt]

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

[nicoddemus]

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.

[bluetech]

@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.

[RonnyPfannschmidt]

@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

[bluetech]

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.

[RonnyPfannschmidt]

The initially linked code shows what they do

[cjw296]

@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!

[bluetech]

What is fixture in this example?

[cjw296]

What is fixture in 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.

[bluetech]

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
    """

[nicoddemus]

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.

[gryznar]

+1 for adding this API

[RonnyPfannschmidt]

The function definition type needs to be hoisted into nodes