Andrew Svetlov <andrew.svet...@gmail.com> 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 AsyncTestCase class? I believe adding async methods to TestCase makes no sense: without instructions how to run async code these methods are pretty useless and error-prone. Implementation of async startup/teardown without providing async runner (read about a runner below) looks like a error. If we mix everything into TestCase we should support virtually both modes in the single TestCase class: one for sync-only test case and other for async tests with async setup/teardown. 3. The next question is: should we support *every not existing yet* async framework by our tools or asyncio-compatible only. *Not existing yet* means we have no idea how to create a test loop, prepare it, run a test by loop, tear down everything. Sure, we can invite a `async function runner` concept but I request a PEP for such significant addition with full specification. Zachary Ware proposed `coroutine_runner` property in `TestCase`. What is `coroutine_runner`? How should it work? How to run a coroutine? Subscribe for a UNIX signal or spawn a subprocess (asyncio has many tricks for signal/subprocess support, pretty sure they are not compatible with curio/trio approach)? Should we expose unified timer/socket/file API? Is it ok that correct asyncio code will fail or even hang if `coroutine_runner` is not compatible with asyncio? If no -- that is benefit of *unified runner* if we need to use concrete runner family for writing tests? In case of limiting build-in `AsyncioTestCase` to asyncio only we narrow down to very well defined asyncio API. Tornado and Twisted declared asyncio compatibility, they should work with the test case class. curio/trio explicitly declared incompatibility with asyncio. That's fine, we should not support them by standard unittest classes too because we have no way to write tests for non-specified-yet contracts. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32972> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
