-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
Add async magic method support to unittest.mock.Mock #70654
Comments
Mock doesn't support stuff like __aexit__ which means you can't mock out something like an async context manager. |
I'm interested in taking this on. I'm considering for this approach, creating a new MagicProxy class specifically for async, and assigning __aexit__ and __aenter__ to those. The __call__ method itself has to be detected as asynchronous, and I don't believe it's possible for a __call__ to behave appropriately for both asynchronous and synchronous cases. |
Taking a look at the code, this may require a bit more discussion. Mock's classes create copies of themselves when an attribute is accessed. As such, I can't just add __aexit__ and have it generate a different mock type entirely, unless I know exactly what an async variant of this mock is. If there was a way to specifically provide a function for asynchronous situations, like __acall__, that would make this a lot easier as well. Anyway, my proposal now is: create new classes MockAsync and MagicMockAsync, and have MockAsync and MagicMockAsync implement the __aexit__ and __aenter__ methods. How is that as an approach? |
There's also __aiter__, but it's semantics might be changing (issue bpo-27243). Robert or Michael, any opinions on Yusuke's proposal? |
I found this while trying to test an async context manager. This is a critical feature to enable migrations to async code, as the impossibility to test something properly is not acceptable in many environments. Implementing it in a way that __call__ returns an object capable of being coroutine or normal function would avoid having to implement Async specific Mocks, wouldn't it? I am not too confident, but would it be doable to have an implementation that depends on whether _is_coroutine is accessed or not? I don't like it, but I really don't like the fact that we need to patch different all the methods depending on whether they are coroutine or not. Obviously, having the __acall__ method would really help solving this issue. |
I guess that it's worth noting that the same problem is being talked about in an issue on the asynctest library: Martiusweb/asynctest#29 |
Perhaps it's possible to vendor asynctest mock in the same vein as The real power of with asynctest.mock.patch("module.Class", autospec=True):
... Where mock instances know what methods are async. |
Added and AsyncMock class which supports mocking async magic methods. |
Adding Lisa to potentially add the PR from Ilya. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: