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...) 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 <http://www.martiusweb.net> Richard www.martiusweb.net