Yury Selivanov <yseliva...@gmail.com> 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 change.
Moreover, I'm not even sure that `AsyncioTestCase` should be in the unittest
module and not in asyncio. Any non-trivial async package I've worked with
usually requires quite a complicated setup to prepare an async test
environment. Usually a test case needs to test against different event loop
policies or different event loops. Which means that we need to support
asynchronous versions of setUp, setUpClass, etc. And I'm not sure we should
just detect when they are asynchronous, perhaps we should make a set of new
methods: asyncSetUp, asyncSetUpClass, etc. This is something that needs more
So far I see that two core asyncio devs are against the proposed idea of
changing unittest.TestCase to support async transparently. IMO it gives almost
no benefits but will complicate the implementation of TestCase and TestRunner
(which are already quite hairy).
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list