Repository navigation
reset_mock resets MagicMock's magic methods in an unexpected way #123934
Description
Activity
- changed the title
[-]reset_mock resets MagicMock's magic methods in an unexpected way[/-][+]`reset_mock` resets `MagicMock`'s magic methods in an unexpected way[/+]on Sep 11, 2024 Thank you for the report. I will take a look soon :)
Reacted by Fabian TschohlSince this child mock now exists, its return value is reset when reset_mock(return_value=True) is called.
Yes, this is correct.
I would expect the same behaviour as Mock. The return value of str and other magic methods should not be effected.
Mockdoes not mock magic methods at all, so they are unaffected at any case. Compare:print(type(mock.Mock().__str__)) # <class 'method-wrapper'> print(type(mock.MagicMock().__str__)) # <class 'unittest.mock.MagicMock'>
But, I agree that retuning
<class 'unittest.mock.MagicMock'>from__str__is not correct.
So, my proposed solution is to ignore cases when:- child is a
MagicMockinstance - key is a magic method
return_valueisTrue
Reacted by Fabian Tschohl- child is a
- added a commit that references this issue
on Sep 19, 2024 - added a commit that references this issue
on Sep 19, 2024 - added a commit that references this issue
on Sep 30, 2024 I see that this test in mu-editor fails with infinite RecursionError:
with mock.patch("builtins.super") as mock_super: pm = PythonMode(editor, view) pm.set_buttons = mock.MagicMock() mock_super.reset_mock()
I believe this is because it is calling reset_mock on a mock of super and after this PR reset_mock calls super.
I think that mocking super is probably dangerous (and always has been), but I thought I should mention this here.
Hm, I think that we can not use
super()for this feature technically. But, I think that mockingsuper()is dangerous indeed.What do others think? Should we fix this?
- added a commit that references this issue
on Nov 18, 2024 FWIW this particular use case was simple enough to fix: mu-editor/mu#2528
Reacted by Fabian Tschohl- added a commit that references this issue
on Dec 13, 2024 Triage: PR merged and backported.
The output on 3.12 and 3.14 is now as expected:
<class 'str'> <class 'str'> <class 'int'> <class 'int'>
Please re-open if there's more to do.
Reacted by Fabian Tschohl- moved this from In Progress to Done in Unittest & doctest issues
on Feb 5, 2025
Bug report
Bug description:
The
reset_mock(return_value=True)method behaves in a wrong/inconsistent way.When used with
MagicMock, the methodreset_mock(return_value=True)does not reset the return values of the magic methods. Only if you call for example__str__and then call the reset_mock function, the return value will be reset, but not to the default value.Output
Since Python 3.9 PR
reset_mocknow also resets child mocks. This explains the behaviour. Calling the__str__method creates a childMagicMockwith a set return value. Since this child mock now exists, its return value is reset when reset_mock(return_value=True) is called.Although this can be logically explained, it's counter-intuitive and annoying as I'm never sure which values are being reset.
I would expect the same behaviour as
Mock. The return value of__str__and other magic methods should not be effected.Output
CPython versions tested on:
3.10
Operating systems tested on:
Linux
Linked PRs
MagicMocknot to reset magic method return values #124038MagicMocknot to reset magic method return values (GH-124038) #124231MagicMocknot to reset magic method return values (GH-124038) #124232