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.gronh...@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 <n...@pobox.com> wrote: >> >>> On Jul 1, 2017 3:11 AM, "Chris Jerdonek" <chris.jerdo...@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
_______________________________________________ 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/
