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

Reply via email to