Repository navigation
--fixtures-per-test: Exclude parametrizing pseudo fixtures? #11295
Description
Activity
You think that
-------------------------- fixtures used by test_one --------------------------- ----------------------------------- (x.py:4) ----------------------------------- monkeypatch -- .../_pytest/monkeypatch.py:30 A convenient fixture for monkey-patching.is clearer to the user?
I am a new user (and a new developer) and I certainly find that clearer.
The expectation I have for a fixture is that
- its author has the option of including a docstring that explains its purpose
- fixtures written by the pytest devs always have docstrings
- fixtures are created using the
pytest.fixture()decorator
If I see a fixture without a docstring, I'd assume I had created it somewhere. Which I would have. But not with the
pytest.fixture()decorator.For me, it would be clearer if either
- the output for
xis removed from--fixtures-per-test's output; or - the output for
xis kept but a docstring tells me it has been generated by pytest to pass an element from thepytest.mark.paramaterize()'s parameter list to the test function
Reacted by Freya BruhinYeah, IMHO those pseudo-fixtures just shouldn't show up there at all.
Reacted by Warren MarkhamI'm eager to start contributing. But am still a novice programmer.
The question of my capability aside, I'm reading through the contribution guide right now to understand what processes of governance/discussion/consensus/etc must turn over their gears before a change of that kind could be officially proposed/developed on.For a smaller change like this, an issue like we have here is a good place for this discussion to take place. Given that there hasn't been any push-back, I'd suggest you go ahead with a pull request! I'm not too familiar with the fixture code myself, but based on gut feeling, this sounds like a good first issue to tackle. Happy to help if you get stock somewhere!
Reacted by Warren MarkhamAmazing. =)
I have things on for the next few days but when I get the chance I'll go through the steps in the Long version of Preparing Pull Requests. Then, once I've implemented a change, I'll do step 11 (submit the pull request through GitHub) with something like:head-fork: WarrenTheRabbit/pytest compare: exclude-parameterising-fixtures-from-fixtures-per-test-output base-fork: pytest-dev/pytest base: mainIt has been over a week since I last commented on this issue so I thought I would share an update as I've made no Pull Request either:
- I fully intend to tackle this issue
- I have started making 'case study' notes that will provide material for a documentation proposal
I first mention the idea of doing a case study in I want to encourage beginners to contribute by making refactoring pull requests:
I think outreach and documentation of all stripes could achieve this. For example, one documentation idea is Case Study documents. Case Study documents would give an example of how a beginner (me) learned how to contribute to pytest. An example of that could be: documenting the work I do on #11295.
- added 2 commits that reference this issue
on Mar 17, 2024 - added a commit that references this issue
on Apr 9, 2026 - added 6 commits that reference this issue
on Jun 18, 2026 - added a commit that references this issue
on Jul 4, 2026 - added a commit that references this issue
on Jul 19, 2026 - added a commit that references this issue
on Aug 17, 2026 - added a commit that references this issue
on Aug 31, 2026
With something like:
running
pytest --fixtures-per-testresults in:IMHO, the output for
xshould be excluded here - while it is technically a (pseudo) fixture internally, showing it like that is rather confusing for users. It doesn't make sense to show it as a fixture without a docstring which is "defined" here:pytest/src/_pytest/fixtures.py
Lines 351 to 352 in d9bf9db