Hi,

asynctest provides a asynctest.TestCase class, inheriting unittest.TestCase. It supports coroutines as test cases and adds a few other useful features like checking that there are no scheduled callbacks left(see http://asynctest.readthedocs.io/en/latest/asynctest.case.html#asynctest.case.asynctest.fail_on) or ClockedTestCase which allows to to control time in the test.

Sorry for the bugs left in asynctest, I try to add as many tests as possible to covers all cases, but I'm having a hard time keeping the library compatible with unittest. A few remarks though:
* keeping the behavior of asynctest in sync with unittest sometimes leads to unexpected behaviors making asynctest look more buggy than it is (at least I hope so...),

* some libraries are hard to mock correctly because they use advanced features, for instance, aiohttp uses its own coroutine type, I still don't know what can be done with those cases,

* I'm also thinking about removing support of python 3.4 (@coroutine decorator, etc) as it's a lot of work.

Unfortunately, I only have a few hours here and there to work on my free time, as I'm not sponsored by my employer anymore. And, as many other open-source libraries out there, I don't receive a lot of feedback nor help :)

Thanks for using (or at least trying to use) asynctest!

Martin

2017-07-04 9:38 GMT+02:00 Alex Grönholm <alex.gronholm@nextday.fi>:

For asyncio, you can write your test functions as coroutines if you use pytest-asyncio. You can even write test fixtures using coroutines. Mocking coroutine functions can be done using asynctest, although I've found that library a bit buggy.

Chris Jerdonek kirjoitti 02.07.2017 klo 00:00:

On Sat, Jul 1, 2017 at 1:42 PM, Nathaniel Smith <njs@pobox.com> wrote:

On Jul 1, 2017 3:11 AM, "Chris Jerdonek" <chris.jerdonek@gmail.com> wrote:
Is there a way to write a test case to check that task.cancel() would
behave correctly if, say, do_things() is waiting at the line
do_more()?

One possibility for handling this case with a minimum of mocking would be to
hook do_more so that it calls task.cancel and then calls the regular
do_more.

Beyond that it depends on what the actual functions are, I guess. If do_more
naturally blocks under some conditions then you might be able to set up
those conditions and then call cancel. Or you could try experimenting with
tests that call sleep(0) a fixed number of times before issuing the cancel,
and repeat with different iteration counts to find different cancel points.

Thanks, Nathaniel. The following would be overkill in my case, but
your suggestion makes me wonder if it would make sense for there to be
testing tools that have functions to do things like "run the event
loop until <this future> is at <this line of code>." Do such things
exist? This is a little bit related to what Dima was saying about
tools.

--Chris
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/

_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/

Martin Richard
www.martiusweb.net