I would like to write an asyncio.unittest package providing a wrapper on top of
the unittest package.
Currently, supported features are described in the README and docstrings.
The next features I plan to add are mocking features:
* when spec is specified, methods decorated with @asyncio.coroutine will be
Does it make sense to detect when a mock is called via "yield from" so we can
make the mock behave like a coroutine even if the decorator is missing?
The idea is to add a simple and comprehensive unit testing framework for
asyncio projects and libraries, aiming at reducing the boilerplate, as well
as unittest does for regular packages.
Some of the things that will be useful:
* when mocking,
* ensure a coroutine or callback won't block for too long (and other features
available through the debug mode of asyncio).
Some of the things that will _probably_ be useful:
* allow to mock parts of the loop when required, such as:
- mock the selector,
- allow triggering fake selector events,
- control the loop clock (thus allowing to fast-forward to run callbacks
in the future)
* specific assertions such as "assert_scheduled", "assert_done",
* make a test fail if the loop don't end in a clean state (uncaught
exception, unfreed resource, etc),
* an asyncio.unittest.mock module, which can mock a coroutine easily (the
trivial way is to mock a coroutine with a future which is done, for
Some more complex/high level things I'd like to do, but which may not be
included in the base "package"
* a mock system allowing to play an exact scenario of events which are
supposed to happen concurrently while the loop run (for instance, complex
network cases involving ConnectionReset, BrokenPipes, etc) - Currently in
my tests, I use actual sockets and yield from asyncio.sleep() to ensure
events happen in the order I expect on the loop, I don't really like it,
* on the other hand, some parts of the asyncio package currently never yield,
but may in the future, I'd like to find a way to test that my code doesn't
use assumptions like that (thus resulting in possible future race
conditions), maybe what I want is a kind of assert_future_done,
* a collection of stream_pair() functions which would return a par of streams
connected to each other,
* a way to mock a program call (allowing to mock asynchronous process
spawning) - actually I'm not sure how I would do this.
Most of those features are features I implemented or should have implemented in
order to get a clean unit test codebase for my project(s) using asyncio.
I am looking for a wishlist of features and feedbacks about what you missed
when writting tests for asyncio libraries, or that made you not write tests.