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#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:https://github.com/Martiusweb/asynctest/issues/29

Perhaps it's possible to vendor asynctest mock in the same vein as `mock` found it's way into unittest?The real power of `asynctest` is in constructs like:with asynctest.mock.patch("module.Class", autospec=True):    ...Where mock instances know what methods are async.

New changeset77b3b7701a34ecf6316469e05b79bb91de2addfa by Lisa Roach in branch 'master':bpo-26467: Adds AsyncMock for asyncio Mock library support (GH-9296)https://github.com/python/cpython/commit/77b3b7701a34ecf6316469e05b79bb91de2addfa

Added and AsyncMock class which supports mocking async magic methods.

Adding Lisa to potentially add the PR from Ilya.

New changesetd6d6e2aa0249bb661541705335ddbb97a53d64c8 by Benjamin Peterson (Ilya Kulakov) in branch 'master':Add Ilya Kulakov toMisc/ACKS. (GH-17130)https://github.com/python/cpython/commit/d6d6e2aa0249bb661541705335ddbb97a53d64c8

New changesete5125f7b3b88d8d4814ed7bddbd4f34d24d763dd by Miss Islington (bot) in branch '3.8':Add Ilya Kulakov toMisc/ACKS. (GH-17130)https://github.com/python/cpython/commit/e5125f7b3b88d8d4814ed7bddbd4f34d24d763dd