> 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 discussion.

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).