[Pulling in comments that were added to a different thread]
On Tue, Jul 4, 2017 at 3:03 AM, Dima Tisnek wrote:
> Come to think of it, what sane tests need is a custom event loop or clever
> mocks around asyncio.sleep, asyncio.Condition.wait, etc. So that code under
> test never sleeps.
> ...
> In
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.async
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
On Mon, Jul 3, 2017 at 10:39 AM, Dima Tisnek wrote:
> I'd say mock 2nd to `await time.sleep(1); assert False, "should not
> happen"` with the earlier just in case test harness or code under test
> is broken.
>
> The tricky part is how to cancel your library function at the right
> time (i.e. not t
I'd say mock 2nd to `await time.sleep(1); assert False, "should not
happen"` with the earlier just in case test harness or code under test
is broken.
The tricky part is how to cancel your library function at the right
time (i.e. not too early).
You could, perhaps, mock 1st call to
`ensure_future(
On Sat, Jul 1, 2017 at 1:42 PM, Nathaniel Smith wrote:
> On Jul 1, 2017 3:11 AM, "Chris Jerdonek" 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 w
On Jul 1, 2017 3:11 AM, "Chris Jerdonek" wrote:
I have a question about testing async code.
Say I have a coroutine:
async def do_things():
await do_something()
await do_more()
await do_even_more()
And future:
task = ensure_future(do_things())
Is there a way to
On Sat, Jul 1, 2017 at 3:49 AM, Dima Tisnek wrote:
> Hi Chris,
>
> This specific test is easy to write (mock first to return a resolved future,
> 2nd to block and 3rd to assert False)
Saying it's easy doesn't necessarily help the questioner. :)
Issues around combinatorics I understand. It's more
GAMBIT: Effective Unit Testing for Concurrency Libraries
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/gambit-ppopp2010.pdf
There are related publications, but I'm pretty sure that's the right
research group.
On 1 July 2017 at 13:15, Yury Selivanov wrote:
>
>> On Jul 1, 201
> On Jul 1, 2017, at 6:49 AM, Dima Tisnek wrote:
>
> There's an academic publication from Microsoft where they built a runtime
> that would run each test really many times, where scheduler is rigged to
> order runnable tasks differently on each run. I hope someone rewrites this
> for asyncio
Hi Chris,
This specific test is easy to write (mock first to return a resolved
future, 2nd to block and 3rd to assert False)
OTOH complexity of the general case is unbounded and generally exponential.
It's akin to testing multithreaded code.
(There's an academic publication from Microsoft where t
I have a question about testing async code.
Say I have a coroutine:
async def do_things():
await do_something()
await do_more()
await do_even_more()
And future:
task = ensure_future(do_things())
Is there a way to write a test case to check that task.cancel() wou
12 matches
Mail list logo
