[issue32972] unittest.TestCase coroutine support

Change by Andrew Svetlov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue32972] unittest.TestCase coroutine support

Andrew Svetlov added the comment: New changeset 0ba5dbd992d68d7df23396148ad55624200a1dbc by Andrew Svetlov (Miss Islington (bot)) in branch '3.8': bpo-32972: Document IsolatedAsyncioTestCase of unittest module (GH-15878) (GH-15918)

[issue32972] unittest.TestCase coroutine support

miss-islington added the comment: New changeset 6a9fd66f6e4445a418c43c92585b9e06d76df4b1 by Miss Islington (bot) (Xtreak) in branch 'master': bpo-32972: Document IsolatedAsyncioTestCase of unittest module (GH-15878)

[issue32972] unittest.TestCase coroutine support

Change by miss-islington : -- pull_requests: +15559 pull_request: https://github.com/python/cpython/pull/15918 ___ Python tracker ___

[issue32972] unittest.TestCase coroutine support

Andrew Svetlov added the comment: Thanks! The test case re-creates a loop per test for the sake of test isolation (scheduled activities from test_a() don't interleave with test_b()). Unfortunately, on the class level level (setUpClass()/tearDownClass()) the loop doesn't exits. There are

[issue32972] unittest.TestCase coroutine support

Karthikeyan Singaravelan added the comment: I did an initial try at the documentation. I think most of the functions are very similar to the TestCase API and I just copied them to add the async related information. I guess it could be improved to keep the length down with still retaining

[issue32972] unittest.TestCase coroutine support

Change by Karthikeyan Singaravelan : -- pull_requests: +15519 pull_request: https://github.com/python/cpython/pull/15878 ___ Python tracker ___

[issue32972] unittest.TestCase coroutine support

Change by Thrlwiti : -- nosy: +THRlWiTi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32972] unittest.TestCase coroutine support

Andrew Svetlov added the comment: Done. Let's keep the issue open until the documentation will be committed -- ___ Python tracker ___

[issue32972] unittest.TestCase coroutine support

miss-islington added the comment: New changeset 4dd3e3f9bbd320f0dd556688e04db0a6b55a7b52 by Miss Islington (bot) (Andrew Svetlov) in branch 'master': bpo-32972: Async test case (GH-13386) https://github.com/python/cpython/commit/4dd3e3f9bbd320f0dd556688e04db0a6b55a7b52 -- nosy:

[issue32972] unittest.TestCase coroutine support

Andrew Svetlov added the comment: https://github.com/python/cpython/pull/13386 is a new attempt to solve the feature request -- ___ Python tracker ___

[issue32972] unittest.TestCase coroutine support

Change by Andrew Svetlov : -- pull_requests: +13301 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32972] unittest.TestCase coroutine support

Dave Shawley added the comment: PR 10296 is my implementation of a unittest.TestCase subclass solution to this issue. This comment explains the approach and rationale in detail. Let's discuss this and see if the implementation meets expectations or should be abandoned. I refactored

[issue32972] unittest.TestCase coroutine support

Dave Shawley added the comment: Hi everyone, I'm trying to reboot conversation on this issue since I would love for this to land in Python 3.8. At the recommendation of Terry Jan Reedy, here is my summary of where I think that the discussion is currently. If anything is misrepresented,

[issue32972] unittest.TestCase coroutine support

Dave Shawley added the comment: I added a different implementation for consideration (https://github.com/python/cpython/pull/10296). -- pull_requests: +9606 ___ Python tracker

[issue32972] unittest.TestCase coroutine support

Petter S added the comment: As far as I am concerned, the discussion can continue in this issue. I still think a reasonable first step is to add a run hook to the regular TestCase class, like in PR 6051. But building consensus is a bit tricky. --

[issue32972] unittest.TestCase coroutine support

Dave Shawley added the comment: Hi all, I took a slightly different direction for adding async/await support to the unittest library. I summarized the approach that I took in a message to python-ideas (https://mail.python.org/pipermail/python-ideas/2018-October/054331.html) and a branch

[issue32972] unittest.TestCase coroutine support

Yury Selivanov added the comment: > - I would say event loop per class. If someone really needs event loop per > method, they can create separate classes per method. It's ugly, but > effective. +1. - We should have an async setUp capability. Maybe we could add a

[issue32972] unittest.TestCase coroutine support

Zachary Ware added the comment: Ok, Yury clarified a few points before I got my message submitted there, so some of my last message may be a bit misguided. In particular, the problems with just using `asyncio.run` are clearer to me now. To give my answers to Yury's

[issue32972] unittest.TestCase coroutine support

Zachary Ware added the comment: 1. I'm still -1 on a separate subclass, especially since the subclass should still be compatible with the base class. 2. This is only in consideration for 3.8 (even 3.7 is past feature freeze at this point), so the version-dependent

[issue32972] unittest.TestCase coroutine support

Yury Selivanov added the comment: First, John and Peter, let's not have two competing PRs. I'd prefer to have only one to make things easier to review. So far it looks like Peter's is slightly more developed. And this also seems to be a complex issue, so there's

[issue32972] unittest.TestCase coroutine support

Petter S added the comment: Personally, I think John's PR is fine. (but the test class could arguably live in asyncio) I like that setUp, tearDown and test methods all can be async. But if setUp and tearDown should never be async as Yury commented above, they

[issue32972] unittest.TestCase coroutine support

Petter S added the comment: John: inspect.iscoroutinefunction(meth) does not work if the method is decorated with e.g. unittest.mock.patch. -- ___ Python tracker

[issue32972] unittest.TestCase coroutine support

John Andersen added the comment: I've updated my pull request to do the following: 1. Provide a new AsyncTestCase class which is a subclass of TestCase 2. Run coroutines with a coroutineRunner property. a. In 3.6 this calls get_evet_loop.run_until_complete b. In

[issue32972] unittest.TestCase coroutine support

Change by Petter S : -- keywords: +patch pull_requests: +5812 stage: -> patch review ___ Python tracker ___

[issue32972] unittest.TestCase coroutine support

Andrew Svetlov added the comment: 1. We have an agreement that we need `asyncSetUp` and all family. I strongly support it. `super()` call is crucial argument I think. 2. Should async setup/teardown methods be a part of `unittest.TestCase` or we need a new

[issue32972] unittest.TestCase coroutine support

Nathaniel Smith added the comment: You should also think about loop lifecycle: right now it's using the same loop for all test cases, so callbacks can leak between tests. Twisted actually goes a step further and explicitly checks for left over callbacks and fails the test if

[issue32972] unittest.TestCase coroutine support

Petter S added the comment: > 1. Do we need support for async versions of setUp, setUpClass, etc? In my > opinion: yes. I completely agree. I would imagine many or most real-world tests requiring async setUp. There is also the question on how a custom loop etc.

[issue32972] unittest.TestCase coroutine support

Yury Selivanov added the comment: > That code does not seem to work for me: > https://gist.github.com/PetterS/f684095a09fd1d8164a4d8b28ce3932d > I get "RuntimeWarning: coroutine 'test_async_with_mock' was never awaited" > @mock.patch needs to work correctly for test

[issue32972] unittest.TestCase coroutine support

Petter S added the comment: > No, it shouldn't break them if you wrap async methods carefully. > Here's a metaclass that I wrote recently doing just that That code does not seem to work for me: https://gist.github.com/PetterS/f684095a09fd1d8164a4d8b28ce3932d I get

[issue32972] unittest.TestCase coroutine support

Nathaniel Smith added the comment: Class decorators are also worth considering in cases where you find yourself reaching for a metaclass. -- nosy: +njs ___ Python tracker

[issue32972] unittest.TestCase coroutine support

Zachary Ware added the comment: Why is a metaclass required? Playing with a modified version of John's PR5938, it doesn't seem necessary. -- ___ Python tracker

[issue32972] unittest.TestCase coroutine support

Yury Selivanov added the comment: > I'm really not seeing what a separate class buys you. I already mentioned in my previous comments that adding async support to unittest.TestCase would require us to add a metaclass to it, which is potentially a backwards incompatible

[issue32972] unittest.TestCase coroutine support

R. David Murray added the comment: I agree with what Zach said in msg313352. I don't see how having a separate class affects the problem of what to use to run an async def test case. If "an AsyncTestCase should be enough" but "other frameworks will require a different

[issue32972] unittest.TestCase coroutine support

Andrew Svetlov added the comment: I'm with Yuri: subclassing is under better control. The need for a new subclass is relative rare, for the whole asyncio world AsyncioTestCase should be enough. Another async framework most likely require a different test tool with

[issue32972] unittest.TestCase coroutine support

Yury Selivanov added the comment: > Doesn't that break when, for example, test methods are decorated with > unittest.mock.patch? No, it shouldn't break them if you wrap async methods carefully. Here's a metaclass that I wrote recently doing just that:

[issue32972] unittest.TestCase coroutine support

Petter S added the comment: > Also, I personally subclassed TestCase in many of my projects specifically to > add async support. To do that you have to use a metaclass to scan class' > namespace for 'async def' functions. Doesn't that break when, for example,

[issue32972] unittest.TestCase coroutine support

Yury Selivanov added the comment: > How is a separate base class better? :) It's very explicit that way. Also, I personally subclassed TestCase in many of my projects specifically to add async support. To do that you have to use a metaclass to scan class' namespace

[issue32972] unittest.TestCase coroutine support

Petter S added the comment: It's good to see others with the same idea as me. I just wrote https://github.com/python/cpython/pull/6005/commits/4d7e1837f235687c875e985e97701609fc1ac458 . In my opinion, there is no need for another test class. I completely agree

[issue32972] unittest.TestCase coroutine support

Zachary Ware added the comment: How is a separate base class better? :) Having a default coroutine runner on the standard TestCase means all you have to do to add async tests is tack an `async` onto the front of your method definition, and everything just works as it

[issue32972] unittest.TestCase coroutine support

Yury Selivanov added the comment: > Instead of a separate base class, what about an overridable > `coroutine_runner` attribute that defaults to `asyncio.run`? How is that better? -- ___ Python tracker

[issue32972] unittest.TestCase coroutine support

Zachary Ware added the comment: Instead of a separate base class, what about an overridable `coroutine_runner` attribute that defaults to `asyncio.run`? -- nosy: +zach.ware ___ Python tracker

[issue32972] unittest.TestCase coroutine support

Yury Selivanov added the comment: I think the right approach would be to add an new base TestCase class: AsyncioTestCase. There other frameworks that have different event loop implementations, so we can't assume that an `async def` test should always be executed by

[issue32972] unittest.TestCase coroutine support

John Andersen added the comment: More discussion indeed. I figured I was not alone in my desire to see async test support in the stdlib. Let me know what other changes would be good. -- ___ Python tracker

[issue32972] unittest.TestCase coroutine support

R. David Murray added the comment: In order for this to be actually useful, I think we also need a mechanism to set up and run async cleanup methods. In my own project I accomplish this by putting the run_until_complete in a try/finally loop and have an

[issue32972] unittest.TestCase coroutine support

New submission from John Andersen : This makes unittest TestCase classes run `test_` methods which are async -- components: Tests, asyncio messages: 313063 nosy: asvetlov, pdxjohnny, yselivanov priority: normal pull_requests: 5708 severity: normal status: open