https://github.com/wimglenn/copyingmock
A subclass of MagicMock that copies the arguments
https://github.com/wimglenn/copyingmock
Last synced: 3 months ago
JSON representation
A subclass of MagicMock that copies the arguments
- Host: GitHub
- URL: https://github.com/wimglenn/copyingmock
- Owner: wimglenn
- License: mit
- Created: 2016-12-06T04:10:06.000Z (over 8 years ago)
- Default Branch: main
- Last Pushed: 2024-11-05T03:00:10.000Z (8 months ago)
- Last Synced: 2025-03-23T19:22:22.834Z (3 months ago)
- Language: Python
- Size: 11.7 KB
- Stars: 6
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
[](https://pypi.org/project/copyingmock/)

[](https://github.com/wimglenn/copyingmock/actions)
[](https://app.codecov.io/gh/wimglenn/copyingmock)
# Copying Mock
`MagicMock` has problems when used on a function with mutable arguments.
This is called out in the [documentation](https://docs.python.org/3/library/unittest.mock-examples.html#coping-with-mutable-arguments):> Another situation is rare, but can bite you, is when your mock is
> called with mutable arguments. `call_args` and `call_args_list` store
> references to the arguments. If the arguments are mutated by the code
> under test then you can no longer make assertions about what the
> values were when the mock was called.They then go on to propose a workaround, using `side_effect`, but it's
not very likable. There is also an elegant recipe offered which copies
arguments at call-time. It's simply a subclass of `MagicMock` which
copies the arguments, instead of storing references. I'm not sure why
the recipe wasn't included directly in `mock`, so here it is as a
third-party package.