setUp and tearDown should be async

[thesamet]

Docs say that classes extending asynctest.TestCase can have either a sync or async. Because the default implementation is sync, it is impossible to write mixins that implement setUp and call super() without checking the result type and awaiting only if it's async. This prevents mixing in mixins that I can't change their existing setUp method.

I think it would be better to have a separate asyncSetup() and asyncTeardown()

See: https://stackoverflow.com/questions/47735156/how-asynctest-testcase-setup-can-be-overridden-by-both-async-and-sync-methods

[Martiusweb]

Hi,

There's indeed a design issue here, but IRCC I decided to keep this to keep the natural orderings of the calls:

• assuming there is no mixin involved, it is easy to decide that the first class inheriting asynctest.TestCase will use a setUp coroutine, and then all the classes inheriting will await super().setUp(),
• doing this ensures that the order of the calls is controlled, because if a class has a setUp() and asyncSetUp(), which one should be called first? Even worse, if a class inherits this class, should we call super().setUp()/asyncSetUp() then the specialized super().setUp()/asyncSetUp() or have the chain of setUp() and asyncSetup() ?

I usually assume that using mixins imples to avoid overriding the same method in several mixins, or that a more complex system is designed to ensure they can all work together without unexpected behaviors (one mixin shadowing another one, etc).

I'm open to new solutions, but I'm slightly concerned that this behavior is currently used by many users of asynctest, and I'm not really keen on changing it in a way that is not backward compatible.

Maybe a mechanism like addSetUp() (similar to addCleanup()) or a Rules system (like implemented in junit, for instance) can be an answer to this.

[Kentzo]

A mixin could inherit from a base class whose setUp / tearDown would check whether the result of a super call is awaitable.