Passing the loop explicitly when writing a library is a good practice, but
not a requirement. Hence, I think that it's better not to break
asyncio.get_event_loop() by default.

However, I will probably add a configuration layer to TestCase in order to
configure the behaviour of the loop (choose the Proactor event loop, for
instance), I can add the option to disable the default loop.

2015-05-12 12:10 GMT+02:00 Andrew Svetlov <[email protected]>:

> Hmm. I always prefer to disable default event loop in tests by
> `asyncio.set_event_loop(None)` call.
>
> On Tue, May 12, 2015 at 10:09 AM, Martin Richard <[email protected]>
> wrote:
> > Ah, too bad I didn't check that before... and I wanted to be
> > "extra-careful"!
> >
> > I changed the name to asynctest and uploaded the project on pypi:
> > https://pypi.python.org/pypi/asynctest
> >
> > Thanks Ludovic!
> >
> > On Monday, May 11, 2015 at 11:39:47 PM UTC+2, Ludovic Gasc wrote:
> >>
> >> Hi Martin,
> >>
> >> Thanks a lot to contribute to improve AsyncIO toolbox.
> >>
> >> However, before to add your library on the wiki page:
> >> https://github.com/python/asyncio/wiki/ThirdParty
> >> I've spotted we already have an AsyncIO library called aiotest, made by
> >> Victor: https://bitbucket.org/haypo/aiotest/ already present on PyPI:
> >> https://pypi.python.org/pypi/aiotest
> >>
> >> I should suggest to rename your library to avoid comprehension errors
> from
> >> newcomers.
> >>
> >> Have a nice night.
> >>
> >> --
> >> Ludovic Gasc (GMLudo)
> >> http://www.gmludo.eu/
> >>
> >> 2015-05-11 22:37 GMT+02:00 Martin Richard <[email protected]>:
> >>>
> >>> Hi,
> >>>
> >>> I would like to talk about a testing library I wrote on top of unittest
> >>> called aiotest. The goal is to provide a package compatible with the
> >>> standard unittest package, but which cuts the boilerplate when testing
> >>> asyncio code.
> >>>
> >>> The code is on github here: https://github.com/Martiusweb/aiotest
> >>>
> >>> I use this library for a project at work, and it currently integrates
> the
> >>> most common features one should need, such as :
> >>>
> >>>  - a TestCase class which creates and recycle the loop after each test,
> >>> allows setUp, tearDown and test functions to be coroutine functions,
> and
> >>> checks that the loop ran during a test,
> >>>  - CoroutineMock, which allows to mock a coroutine, and modified
> versions
> >>> of Mock, MagicMock which can return a CoroutineMock object instead of a
> >>> MagicMock object when a spec or spec_set is defined and the original
> member
> >>> of the mocked object/class is a coroutine function,
> >>>  - mock.patch() are also updated so they return the enhanced Mock and
> >>> MagickMock objects, or CoroutineMock is the patched value is a
> coroutine
> >>> function.
> >>>
> >>> I will add the package to PyPI later this week, since It's my first
> >>> package, I'd like to be extra careful.
> >>>
> >>> I am obviously open to suggestions, feature requests and bug reports!
> >>>
> >>> Cheers,
> >>> Martin
> >>
> >>
> >
>
>
>
> --
> Thanks,
> Andrew Svetlov
>



-- 
Martin Richard
www.martiusweb.net

Reply via email to