fixtures: match fixtures based on actual node hierarchy, not textual nodeids #11785
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bluetech
force-pushed
the
matchfactories-nodes
branch
from
1531eed
to
29a8bda
Compare
|
Looking at plugins from my local corpus: Affected by
Affected by
Affected by
I've considered deprecations but since these are private APIs and the fixes are not very difficult, I've decided not to. Instead, I added a changelog entry and will open issues for the projects above if this PR is merged. |
nicoddemus
approved these changes
Jan 8, 2024
| - ``FixtureManager._getautousenames()`` now takes a ``Node`` itself instead of the nodeid. | ||
| - ``FixtureManager.getfixturedefs()`` now takes the ``Node`` itself instead of the nodeid. | ||
| - The ``_pytest.nodes.iterparentnodeids()`` function is removed without replacement. | ||
| Prefer to traverse the node hierarchy itself instead. |
There was a problem hiding this comment.
Suggested change
| Prefer to traverse the node hierarchy itself instead. | |
| Prefer to traverse the node hierarchy itself using ``_pytest.nodes.iterparentnodes()`` instead. |
There was a problem hiding this comment.
Oh, I now realize that you might not want to advertise the internal function on purpose -- if that's the case feel free to ignore this.
There was a problem hiding this comment.
Right, I don't mean to expose it. I think it can be nice as a Node method, maybe later.
…nodeids Refs pytest-dev#11662. --- Problem Each fixture definition has a "visibility", the `FixtureDef.baseid` attribute. This is nodeid-like string. When a certain `node` requests a certain fixture name, we match node's nodeid against the fixture definitions with this name. The matching currently happens on the *textual* representation of the nodeid - we split `node.nodeid` to its "parent nodeids" and then check if the fixture's `baseid` is in there. While this has worked so far, we really should try to avoid textual manipulation of nodeids as much as possible. It has also caused problem in an odd case of a `Package` in the root directory: the `Package` gets nodeid `.`, while a `Module` in it gets nodeid `test_module.py`. And textually, `.` is not a parent of `test_module.py`. --- Solution Avoid this entirely by just checking the node hierarchy itself. This is made possible by the fact that we now have proper `Directory` nodes (`Dir` or `Package`) for the entire hierarchy. Also do the same for `_getautousenames` which is a similar deal. The `iterparentnodeids` function is no longer used and is removed.
bluetech
force-pushed
the
matchfactories-nodes
branch
from
bcfc853
to
992d0f0
Compare
|
Temporarily disabled pytest-bdd plugin check until it's updated |
bluetech
added a commit
to bluetech/pytest-factoryboy
that referenced
this pull request
Jan 8, 2024
The signature of this (private) function will change in the upcoming pytest 8.1 release: pytest-dev/pytest#11785 I verified that all tests pass when run against pytest main.
bluetech
added a commit
to bluetech/pytest-bdd
that referenced
this pull request
Jan 8, 2024
The signature of this (private) function will change in the upcoming pytest 8.1 release: pytest-dev/pytest#11785 Additionally, the `iterparentnodeids` function is removed, so copy/pasting it for now. I verified that all tests pass when run against pytest main.
bluetech
added a commit
to bluetech/python-pytest-harvest
that referenced
this pull request
Jan 8, 2024
The signature of this (private) function will change in the upcoming pytest 8.1 release: pytest-dev/pytest#11785
bluetech
added a commit
to bluetech/python-pytest-harvest
that referenced
this pull request
Jan 8, 2024
The signature of this (private) function will change in the upcoming pytest 8.1 release: pytest-dev/pytest#11785
bluetech
added a commit
to bluetech/python-pytest-cases
that referenced
this pull request
Jan 8, 2024
The signature of this (private) function will change in the upcoming pytest 8.1 release: pytest-dev/pytest#11785
bluetech
added a commit
to bluetech/python-pytest-cases
that referenced
this pull request
Jan 11, 2024
The signature of this (private) function will change in the upcoming pytest 8.1 release: pytest-dev/pytest#11785
smarie
pushed a commit
to smarie/python-pytest-cases
that referenced
this pull request
Jan 12, 2024
The signature of this (private) function will change in the upcoming pytest 8.1 release: pytest-dev/pytest#11785
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Refs #11662.
Problem
Each fixture definition has a "visibility", the
FixtureDef.baseidattribute. This is nodeid-like string. When a certainnoderequests a certain fixture name, we match node's nodeid against the fixture definitions with this name.The matching currently happens on the textual representation of the nodeid - we split
node.nodeidto its "parent nodeids" and then check if the fixture'sbaseidis in there.While this has worked so far, we really should try to avoid textual manipulation of nodeids as much as possible. It has also caused problem in an odd case of a
Packagein the root directory: thePackagegets nodeid., while aModulein it gets nodeidtest_module.py. And textually,.is not a parent oftest_module.py.Solution
Avoid this entirely by just checking the node hierarchy itself. This is made possible by the fact that we now have proper
Directorynodes (DirorPackage) for the entire hierarchy.Also do the same for
_getautousenameswhich is a similar deal.The
iterparentnodeidsfunction is no longer used and is removed.