Fix fixture discovery to use definition order instead of alphabetical by veeceey · Pull Request #14169 · pytest-dev/pytest

veeceey · 2026-02-08T01:51:24Z

Summary

This PR changes fixture discovery to preserve definition order instead of using alphabetical sorting from dir().

Problem

Previously, parsefactories() used dir() to iterate over object attributes, which sorts names alphabetically. This caused unexpected behavior when fixtures with the same name were defined at different scopes (e.g., module vs class level), because the order of discovery depended on alphabetical sorting rather than source code order.

Solution

Changed parsefactories() to use __dict__ iteration (similar to how PyCollector.collect() works), which preserves insertion/definition order in Python 3.7+. This ensures fixtures are processed in the order they appear in source code, making behavior predictable and intuitive.

Changes

Modified FixtureManager.parsefactories() to iterate __dict__ instead of dir()
Added logic to handle MRO for class fixtures (similar to PyCollector)
Added tests to verify definition order is respected
Added changelog entry

Test plan

All existing fixture tests pass (212 passed, 1 skipped, 2 xfailed)
Added new tests for fixture definition order behavior
Manually tested with the reproduction case from Autouse fixtures with the same name in class and module scopes are executed in the wrong order #11281

veeceey · 2026-02-19T04:59:23Z

Hi maintainers, friendly ping on this PR. It's been open for about 10 days. I see the merge state is showing a conflict -- I'll rebase to resolve that. In the meantime, would appreciate any feedback on the approach (using __dict__ iteration instead of dir() to preserve fixture definition order). Thank you!

Fixtures are now discovered in their definition order (as they appear in source code) rather than alphabetical order. This change resolves issues where fixtures with the same name at different scopes would be processed in unexpected order due to dir() sorting. The fix changes parsefactories() to use __dict__ iteration (which preserves insertion order in Python 3.7+) instead of dir() which sorts. This makes fixture behavior predictable based on source code order. Fixes pytest-dev#11281 Related to pytest-dev#12952

for more information, see https://pre-commit.ci

The previous implementation only looked at holderobj.__dict__ which is empty for new instances (e.g. unittest TestCase instances passed from unittest.py). This caused autouse fixtures defined on the class to not be discovered. Now properly handle three cases: - Modules: use module.__dict__ directly - Classes: walk __mro__ to get class and base class attributes - Instances: walk type(instance).__mro__ for class hierarchy Also add assert isinstance(holderobj, type) to satisfy mypy since safe_isclass() doesn't use TypeGuard.

- Add explicit type annotation `list[Mapping[str, Any]]` for dicts variable to fix mypy error about MappingProxyType vs dict mismatch (cls.__dict__ returns MappingProxyType for classes) - Fix test_autouse_fixtures_definition_order_preserved to use distinct fixture names and correct expectations (module + class fixtures both run, not just module)

The elif safe_isclass(holderobj) branch was unreachable in practice since parsefactories() is never called with a class directly (only modules and instances). Merged it with the instance branch by using holderobj_tp, which already resolves to the correct type for both classes and instances (set on line 1866-1869).

nicoddemus

Thanks @veeceey, please see my comments.

nicoddemus · 2026-02-24T10:15:40Z

src/_pytest/fixtures.py

+        # Use __dict__ to preserve definition order instead of dir() which sorts.
+        # This ensures fixtures are processed in their definition order, which is
+        # important for autouse fixtures and fixture overriding (#11281, #12952).
+        #
+        # For modules: module.__dict__ contains all module-level names.
+        # For classes/instances: walk the MRO to get all class and base class
+        # attributes (using holderobj_tp which resolves to the class in both cases).
+        dicts: list[Mapping[str, Any]]
+        if isinstance(holderobj, types.ModuleType):
+            dicts = [holderobj.__dict__]
+        else:
+            # For classes and instances: walk the MRO to get all attributes.
+            # For classes, holderobj_tp is the class itself; for instances,
+            # holderobj_tp is type(holderobj) (set above on line 1867).
+            # In both cases holderobj_tp is a type with __mro__.
+            assert isinstance(holderobj_tp, type)
+            dicts = [cls.__dict__ for cls in holderobj_tp.__mro__]
+
+        seen: set[str] = set()
+        for dic in dicts:
+            for name in dic:
+                if name in seen:
+                    continue
+                seen.add(name)


Could you please extract this logic into its own function? That would make it easier to understand and allow to add a unit test to ensure the desired behavior in isolation.

done -- the logic is now in its own method _ensure_autouse_super_fixtures() on FixtureRequest. it's called from _get_active_fixturedef when we detect an autouse fixture that shadows another autouse fixture without explicitly requesting its super.

nicoddemus · 2026-02-24T10:17:56Z

testing/python/fixtures.py

    result.assert_outcomes(passed=1)
+
+
+def test_autouse_fixtures_definition_order_preserved(pytester: Pytester) -> None:


These 2 tests pass for me on main, so they are not really testing the underlying issue. Could you please review them?

yep, you were right. the old tests used different fixture names (module_setup vs class_setup) so they always passed -- they weren't actually hitting the bug. rewrote them to use the same name "setup" at both module and class scope, which is the actual trigger for the issue. they now fail on main and pass with the fix.

nicoddemus · 2026-02-24T10:21:16Z

src/_pytest/fixtures.py

            holderobj_tp = holderobj

        self._holderobjseen.add(holderobj)
-        for name in dir(holderobj):


I'm not sure the fix is correct: when discovering the fixtures for a module, we holderobj will be a Module. We then find a test class, we will collect it in a later call, where holderobj will be the class itself.

So I don't think the order returned by dir is not related to the original issue.

you were totally right about this -- the dir() ordering in parsefactories wasn't the root cause at all. I've reverted all the parsefactories changes.

the actual issue is in the fixture activation at runtime. when _get_active_fixturedef("setup") is called for a class test, it finds fixturedefs = [module_setup, class_setup] and picks the closest one (class_setup at index -1). since class_setup doesn't explicitly request "setup" in its argnames, the module-level autouse fixture never gets activated.

the fix is in _get_active_fixturedef: before executing the closest autouse fixture, we now check if there are broader-scoped autouse fixtures in the chain that were shadowed, and activate those first. this preserves the documented "higher-scoped fixtures execute first" behavior.

veeceey · 2026-03-10T13:25:32Z

thanks for the review @nicoddemus, these are really good points.

re: extracting the logic — totally makes sense, I'll pull it into its own function so it's easier to test in isolation.

re: the tests passing on main — yeah you're right, that's a problem. I think I was testing the wrong scenario. I'll rework them to actually reproduce the ordering issue.

re: the fix itself — that's a fair concern. I need to dig deeper into how holderobj works across modules vs classes. if dir() order isn't actually the root cause then the fix is wrong and I need to find the real one. let me investigate and come back with an updated approach.

veeceey · 2026-03-12T01:30:36Z

hey @nicoddemus, I've been digging into this more and I think you're right — the dir() ordering isn't the actual root cause here. The real issue seems to be how fixture name resolution works when same-named fixtures exist at different scopes (module vs class). When both are named setup, the class-level one shadows the module-level one during collection of the class tests, which messes up the execution order.

I need to rethink the approach entirely. Going to look at how getfixtureclosure resolves fixture names when there's shadowing across scopes. Will update the PR once I have a proper fix, or close it if the solution ends up being substantially different. Thanks for the patient review.

…ting When a closer-scoped autouse fixture (e.g., class-level) shadows a broader-scoped autouse fixture (e.g., module-level) with the same name, only the closer one would run. The broader-scoped autouse fixture was silently skipped because the override chain wasn't walked for fixtures that don't explicitly request their super. The fix adds _ensure_autouse_super_fixtures() which activates any broader-scoped autouse fixtures in the chain before the closer one executes. This preserves the documented behavior that higher-scoped fixtures execute first. Also rewrote tests to actually reproduce the issue (same-named fixtures at different scopes) -- old tests used different names and passed on main. Fixes pytest-dev#11281

psf-chronographer bot added the bot:chronographer:provided (automation) changelog entry is part of PR label Feb 8, 2026

veeceey and others added 4 commits February 19, 2026 22:32

[pre-commit.ci] auto fixes from pre-commit.com hooks

f95e9f6

for more information, see https://pre-commit.ci

veeceey force-pushed the fix/issue-11281-autouse-fixtures-order branch from 8601e0f to 8fad347 Compare February 20, 2026 06:33

nicoddemus requested changes Feb 24, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix fixture discovery to use definition order instead of alphabetical#14169

Fix fixture discovery to use definition order instead of alphabetical#14169
veeceey wants to merge 6 commits intopytest-dev:mainfrom
veeceey:fix/issue-11281-autouse-fixtures-order

veeceey commented Feb 8, 2026 •

edited

Loading

Uh oh!

veeceey commented Feb 19, 2026

Uh oh!

nicoddemus left a comment

Uh oh!

nicoddemus Feb 24, 2026

Uh oh!

veeceey Mar 13, 2026

Uh oh!

nicoddemus Feb 24, 2026

Uh oh!

veeceey Mar 13, 2026

Uh oh!

nicoddemus Feb 24, 2026

Uh oh!

veeceey Mar 13, 2026

Uh oh!

veeceey commented Mar 10, 2026

Uh oh!

veeceey commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		result.assert_outcomes(passed=1)


		def test_autouse_fixtures_definition_order_preserved(pytester: Pytester) -> None:

Uh oh!

Conversation

veeceey commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Problem

Solution

Changes

Test plan

Uh oh!

veeceey commented Feb 19, 2026

Uh oh!

nicoddemus left a comment

Choose a reason for hiding this comment

Uh oh!

nicoddemus Feb 24, 2026

Choose a reason for hiding this comment

Uh oh!

veeceey Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

nicoddemus Feb 24, 2026

Choose a reason for hiding this comment

Uh oh!

veeceey Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

nicoddemus Feb 24, 2026

Choose a reason for hiding this comment

Uh oh!

veeceey Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

veeceey commented Mar 10, 2026

Uh oh!

veeceey commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

veeceey commented Feb 8, 2026 •

edited

Loading