fix: iter_markers/get_closest_marker returns correct closest MRO marker (#14329)

[RonnyPfannschmidt]

Alternative approach to #14332 for fixing #14329 (get_closest_marker returning the wrong marker with class inheritance).

The regression test is Wintreist's, taken from #14332 — thanks for it, and for the patience.

• Introduces Node._iter_own_markers_closest_first(), overridden by Class to walk the MRO in natural closest-first order while preserving decorator stacking order within each class
• Does not change own_markers order — it stays in base-first (construction) order
• Reverses usefixtures marker iteration to maintain farthest-first fixture setup ordering

Key difference from #14332

#14332 reverses the MRO traversal in get_unpacked_marks, which changes own_markers order on Class nodes. This approach keeps own_markers unchanged and fixes the iteration layer (iter_markers / get_closest_marker), which is the actual consumer that needs closest-first semantics.

The concrete difference is keywords. PyobjMixin.obj does
self.keywords.update((mark.name, mark) for mark in self.own_markers) — last wins — so with
base-first own_markers the closest mark is the one that ends up in keywords. Reversing
own_markers silently flips that to the base mark:

@pytest.mark.foo("base")
class TestBase: pass

@pytest.mark.foo("child")
class TestChild(TestBase):
    def test_it(self, request):
        request.node.parent.keywords["foo"].args[0]  # "child" here / on main, "base" with #14332

No test covers this today (test_collection.py uses distinct mark names across levels), so it
goes unnoticed. It is fixable in #14332 with a reversed(), but it is the reason this PR
targets iteration instead.

Behaviour changes to be aware of

Both this PR and #14332 share these — they follow from closest-first iteration itself, not from
either implementation:

• Inherited class level parametrize composes IDs in the opposite order.
  _genfunctions consumes definition.iter_markers("parametrize"), so a base class
  @pytest.mark.parametrize("a", ...) combined with a subclass @pytest.mark.parametrize("b", ...)
  now yields TestChild::test_it[x-1] where it used to yield TestChild::test_it[1-x].
  Selections pinned to such IDs and the --last-failed cache need regenerating. Documented in the
  changelog.
• Stacked usefixtures markers on one node request their fixtures in source order.
  _getusefixturesnames reverses the full iter_markers_with_node result, within a node as well
  as across the collection chain. That is deliberate: markers are stored bottom-up, so reversing
  makes two stacked @pytest.mark.usefixtures decorators behave like a single
  usefixtures("a", "b"). Pinned by test_mark_fixture_order_usefixtures_stacking.

Also here: pytestmark accepts any sequence

Answering @nicoddemus' review question — any sequence will do, not just a list:

class TestThings:
    pytestmark = (pytest.mark.a, pytest.mark.b)   # TypeError before, works now

This started as an accident: routing the MRO walk through the new get_mro_mark_groups()
made tuples work for inherited class marks only, while consider_mro=False and
module/function pytestmark still rejected them. Rather than leave the three paths
disagreeing, they now share one _as_mark_sequence() helper. str/bytes are deliberately
excluded, so an accidental pytestmark = "xfail" still reports the string itself rather than
its first character. Separate changelog/14630.improvement.rst.

Test plan

• test_mark_closest_mro — closest-first MRO marker resolution (from BugFix #14329 #14332)
• test_mark_closest_mro_with_dynamic_class_marker — add_marker(append=) keeps its position relative to MRO markers
• test_mark_mro_marker_object_reused_by_add_marker — the same Mark object reaching own_markers via both the MRO and add_marker no longer aborts collection with RuntimeError: generator raised StopIteration
• test_mark_fixture_order_usefixtures_stacking — stacked usefixtures order
• Existing test_mark_mro / get_unpacked_marks tests pass unchanged (own_markers order preserved)
• Full suite green locally (4357 passed), mypy and pre-commit clean
• Full CI

Interaction with other open PRs

• WIP: dense CallSpec, lazy NodeKeywords, deferred TopRequest #14766 derives keywords lazily and resolves a name by scanning own_markers first-wins,
  where today's dict.update is last-wins. On top of this PR that flips
  Class.keywords["foo"] to the base class mark; it needs reversed() there (and the opposite
  if BugFix #14329 #14332 lands instead).
• Definition fixture scope and a generic ItemDefinition node (#3926) #14805 and Accept MarkDecorator as get_closest_marker default #14833 conflict textually only.

[Copilot]

Pull request overview

Fixes marker resolution for inherited test classes so iter_markers/get_closest_marker return the closest (most-derived) class’ marks first, while attempting to preserve backward-compatible own_markers ordering and existing fixture-setup behavior.

Changes:

• Add Node._iter_own_markers_closest_first() and switch marker iteration to use it for closest-first semantics.
• Override marker iteration for python.Class to traverse class MRO in closest-first order while preserving per-class decorator stacking.
• Adjust usefixtures processing to preserve farthest-first fixture requesting, and add regression tests + changelog entry.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
testing/test_mark.py	Adds regression tests for closest-first MRO marker resolution and updates a mock-based test for the new iteration hook.
src/_pytest/python.py	Implements Class._iter_own_markers_closest_first() and introduces an override decorator compatibility shim.
src/_pytest/nodes.py	Routes marker iteration through _iter_own_markers_closest_first() and updates docstrings to state closest-first behavior.
src/_pytest/fixtures.py	Reverses usefixtures marker iteration to keep farthest-first fixture request ordering after marker iteration changes.
changelog/14329.bugfix.rst	Documents the bugfix for closest marker resolution with class inheritance.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Wintreist]

Hi!
Thank you for continuing to work on this PR. I am really looking forward to its appearance in the main branch of pytest. Once again, I ran into the get_closest_marker problem and will have to write a crutch until you finish the PR.