Repository navigation
pytest silently chooses the wrong fixture when two plugins declare a fixture with the same name #3966
Description
The magic name-matching of pytest's fixtures can lead to namespace clashes, apart from being unpythonic (see #3834). Getting a wrong fixture may lead to hard-to-debug errors, especially if one does not know the plugin code and therefore does not know if one plugin may legitimately call the other plugin's code. Thus, I believe that pytest should not allow a fixture to be used whose name clashes between two declarations (Python Zen: In the face of ambiguity, refuse the temptation to guess.). Instead, it should raise an explicit error, including a hint to the test-writer how they may resolve the ambiguity.
The environment where this bug was observed was the following:
python 3.6.1
This is pytest version 3.5.0
pytest-sanic-0.1.13
pytest-benchmark-3.1.1
pytest-aiohttp-0.3.0
where both aiohttp and sanic provide a test_client fixture.
Activity
Zac-HD commentedon Oct 19, 2018
I support pytest raising an explicit error whenever it would otherwise choose between multiple fixtures 👍
IMO this has never worked and we could go to an error straight away, but if others disagree we might need a deprecation period first.
RonnyPfannschmidt commentedon Oct 19, 2018
we have to account for layered fixture overrides however
def myfixture(myfixture): ...is supported as a customization system for pluginsadditionally i believe pytest-selenium uses those overrides in order to allow local testsuites to customize certain settings
Zac-HD commentedon Oct 19, 2018
😱... this isn't a fatal problem though, because in this case it's always the more-recently-defined fixture that should be chosen.
We can therefore ignore "parent" fixtures, but still error on unrelated or "sibling" fixtures.
RonnyPfannschmidt commentedon Oct 19, 2018
detecting sieblings correctly will be tricky
i propose to introduce a flag for fixtures that are supposed to be overridden, and then only warning on fixtures that override fixtures that are not meant for overriding
RonnyPfannschmidt commentedon Oct 19, 2018
that way we can count the existence of
myfixture(myfixture)as externally allowed override and and afixture(..., allow_override=True)marking as internally allowed overrideZac-HD commentedon Oct 19, 2018
So long as we can tell what (if any) fixtures a given fixture layers on, it's just a matter of walking back up that tree looking for the conflicting fixtures. And if there are no conflicting fixtures we don't need to do anything, so the performance should be fine.
Creating a distinction between fixtures that can and cannot be overridden seems likely to cause lots of subtle problems about ordering and sequences of fixtures, so I'd avoid it.
RonnyPfannschmidt commentedon Oct 19, 2018
we already have a situation where overriding is used as a feature, so we cant break it
we have explicit overrides where we take in the original fixture as a input value, and we have implicit overrides, where a different definition is supposed to be allowed to be overridden
from my pov we want to to warn of all overrides but
Zac-HD commentedon Oct 19, 2018
Yep, that sounds like a good plan 🚀
dhensen commentedon Dec 10, 2021
Is there some kind of summary of what the current status is? I'm finding this in 2021 after weird errors using pandas. It turns out pandas defines a fixture called
s3_resource. We similarly named fixture in our own code. I think we will run into more problems with generically named fixtures (think of this: s3_client, ddb_client, ddb_resource, etc....).Ideally I do not want to rename. Currently I don't see any warning about duplicate fixtures, at a certain point I started getting failing tests. It seems random, I don't get it yet. Using pytest 6.2.2
dhensen commentedon Dec 10, 2021
Excuse me, turned out I made a mistake. When creating a bucket with s3 resource (instead of client) you have to specify a
CreateBucketConfiguration. I did not do that.I could conclude I was wrong after having read the docs about fixture scopes and how pytest resolves fixtures when third party libs are involved.
crashvb commentedon Feb 1, 2022
Is there a workaround, or way to select between the two conflicting fixtures? If so, does it apply to nested fixture resolution?
I am experiencing this issue after import two libraries that provide the same fixtures of the same name, as-well-as, those fixtures using nested fixtures of the same name ...
Prefix fixtures to prevent conflicts until pytest-dev/pytest#3966 is …
Prefix fixtures to prevent conflicts until pytest-dev/pytest#3966 is …
nicoddemus commentedon Feb 2, 2022
There's no workaround currently AFAIK, I'm afraid.
Prefix fixtures to prevent conflicts until pytest-dev/pytest#3966 is …
DetachHead commentedon Jul 18, 2025
this also commonly occurs with
autousefixtures. since we assumed the name doesn't matter because the fixture is never explicitly requested, we've been giving all our autouse fixtures the same name:RonnyPfannschmidt commentedon Jul 18, 2025
oh, that usage pattern makes fixing this more critical - personally I always gave autouse fixtures names that exactly tell what they involve or scope them specifically to classes or modules - so it didn’t occur to me that this type of conflict is a problem users will face