[Async-sig] async testing question

[Martin Richard]

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 at 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 at pobox.com> wrote:
>>
>>> On Jul 1, 2017 3:11 AM, "Chris Jerdonek" <chris.jerdonek at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20170704/5100af68/attachment.html>