-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pytest 8.1.0 AttributeError: 'NoneType' object has no attribute 'setup_method' with staticmethod test #12065
Comments
I see the failing test is a staticmethod: I'm not sure if that's supposed to work (will check later), but curious if there's a particular reason you made it staticmethod? |
Oh, thanks. No, in fact that does not have to be a staticmethod. Let me remove that and test again. |
There exists another CI workflow (named "Examples") that is also passing on 8.0.2 and failing with 8.1.0. That does not use staticmethod. 8.0.2 Examples CI: https://github.com/BlueBrain/BlueCelluLab/actions/runs/8114860416/job/22181463086 |
@anilbey This is a different issue, the |
Update: removing 'staticmethod' worked. Great, thanks a lot @bluetech for your quick reply in clarifying the issues. |
Bisected to c8792bd (pr #11780). We're talking about this reproduction: class TestIt:
def setup_method(self): pass
@staticmethod
def test_1(): pass This brings up the question, what is The expectation, as happens with e.g. unittest and regular methods, is that it's a fresh instance. However, pytest<=8.0 has a subtle bug: all of the static/classmethods use a shared instance. The two prints here are the same: class TestIt:
def setup_method(self): print('\nSETUP!', self)
@staticmethod
def test_1(): pass
@classmethod
def test_2(cls): pass I think that fixing this preexisting bug will also fix the 8.1.0 crash, so I will look into it, though it probably won't be a simple fix, so I might instead restore the previous (problematic) behavior. |
TODO: Clear `_instance` when `_obj` is cleared. and also fixes a regression in pytest 8.0.0 where `setup_method` crashes if the class has static or class method tests. It is allowed to have a test class with static/class methods which request non-static/class method fixtures (including `setup_method` xunit-fixture). I take it as a given that we need to support this somewhat odd scenario (stdlib unittest also supports it). This raises a question -- when a staticmethod test requests a bound fixture, what is that fixture's `self`? stdlib unittest says - a fresh instance for the test. Previously, pytest said - some instance that is shared by all static/class methods. This is definitely broken since it breaks test isolation. Change pytest to behave like stdlib unittest here. In practice, this means stopping to rely on `self.obj.__self__` to get to the instance from the test function's binding. This doesn't work because staticmethods are not bound to anything. Instead, keep the instance explicitly and use that. BTW, I think this will allow us to change `Class`'s fixture collection (`parsefactories`) to happen on the class itself instead of a class instance, allowing us to avoid one class instantiation. But needs more work. Fixes pytest-dev#12065.
and also fixes a regression in pytest 8.0.0 where `setup_method` crashes if the class has static or class method tests. It is allowed to have a test class with static/class methods which request non-static/class method fixtures (including `setup_method` xunit-fixture). I take it as a given that we need to support this somewhat odd scenario (stdlib unittest also supports it). This raises a question -- when a staticmethod test requests a bound fixture, what is that fixture's `self`? stdlib unittest says - a fresh instance for the test. Previously, pytest said - some instance that is shared by all static/class methods. This is definitely broken since it breaks test isolation. Change pytest to behave like stdlib unittest here. In practice, this means stopping to rely on `self.obj.__self__` to get to the instance from the test function's binding. This doesn't work because staticmethods are not bound to anything. Instead, keep the instance explicitly and use that. BTW, I think this will allow us to change `Class`'s fixture collection (`parsefactories`) to happen on the class itself instead of a class instance, allowing us to avoid one class instantiation. But needs more work. Fixes pytest-dev#12065.
and also fixes a regression in pytest 8.0.0 where `setup_method` crashes if the class has static or class method tests. It is allowed to have a test class with static/class methods which request non-static/class method fixtures (including `setup_method` xunit-fixture). I take it as a given that we need to support this somewhat odd scenario (stdlib unittest also supports it). This raises a question -- when a staticmethod test requests a bound fixture, what is that fixture's `self`? stdlib unittest says - a fresh instance for the test. Previously, pytest said - some instance that is shared by all static/class methods. This is definitely broken since it breaks test isolation. Change pytest to behave like stdlib unittest here. In practice, this means stopping to rely on `self.obj.__self__` to get to the instance from the test function's binding. This doesn't work because staticmethods are not bound to anything. Instead, keep the instance explicitly and use that. BTW, I think this will allow us to change `Class`'s fixture collection (`parsefactories`) to happen on the class itself instead of a class instance, allowing us to avoid one class instantiation. But needs more work. Fixes pytest-dev#12065.
It cannot work reliably, see pytest-dev/pytest#12065.
It cannot work reliably, see pytest-dev/pytest#12065.
It cannot work reliably, see pytest-dev/pytest#12065.
Hi, the code that was working fine with pytest==8.0.2 started giving the error below for pytest==8.1.0.
Logs with pytest 8.0.2: https://github.com/BlueBrain/BlueCelluLab/actions/runs/8114860416/job/22181464420
Logs with pytest 8.1.0: https://github.com/BlueBrain/BlueCelluLab/actions/runs/8138274377/job/22239015810?pr=142
All of the installed dependencies and the system versions are available in the CI logs.
The text was updated successfully, but these errors were encountered: