Pytest async fixtures

[k4nar]

What do these changes do?

With this PR, pytest fixtures can be coroutines. For example, in order to create a client, you can use:

@pytest.fixture
async def cli(test_client):
    return await test_client(setup_app)

This is not a killer feature as you could already do the same thing using loop.run_until_complete, but I find it more idiomatic.

The main gotcha is that in order for an async fixture to work, it must use the loop fixture, or be called in a test using it. The previous example works because test_client uses the loop fixture.
I don't think this is a big issue because I can't think of any case where one would want an asynchronous fixture without using the loop.

Are there changes in behavior for the user?

None.

Related issue number

#2223

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the changes folder
  • name it <issue_id>.<type> for example (588.bug)
  • if you don't have an issue_id change it to the pr id after creating the pr
  • ensure type is one of the following:
    • .feature: Signifying a new feature.
    • .bugfix: Signifying a bug fix.
    • .doc: Signifying a documentation improvement.
    • .removal: Signifying a deprecation or removal of public API.
    • .misc: A ticket has been closed, but it is not of interest to users.
  • Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files."

[codecov-io]

Codecov Report

Merging #2226 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master   #2226      +/-   ##
=========================================
+ Coverage   97.29%   97.3%   +0.01%     
=========================================
  Files          39      39              
  Lines        8016    8051      +35     
  Branches     1388    1395       +7     
=========================================
+ Hits         7799    7834      +35     
  Misses         94      94              
  Partials      123     123

Impacted Files	Coverage Δ
aiohttp/pytest_plugin.py	97.36% <100%> (+0.64%)	⬆️
aiohttp/helpers.py	97.27% <100%> (+0.03%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b1f5afd...43c67aa. Read the comment docs.

[asvetlov]

Your PR is awesome!
I really love it.

Would you add add couple words to http://aiohttp.readthedocs.io/en/stable/testing.html#pytest for introducing the feature?

[k4nar]

Yes I'll had some documentation soon. I wanted to have some feedback first, but now we're good :) .

[mikenerone]

Just a note based on a glance at this (so apologies if I'm missing some important difference), but this seems like reinventing pytest-asyncio, which provides a more robust feature set. aiohttp already has deps on some other pytest plugins, and this seems like a natural one to add to that set.

[asvetlov]

LGTM

[asvetlov]

Thanks!

[samuelcolvin]

Despite my initial scepticism, this looks like it should be really useful.

Thanks a @k4nar, you'll save me writing loop.run_until_complete a few hundred times a year.

[mikenerone]

@asvetlov @k4nar I guess my comment went under the radar, as there was no response. I'll mention it just this one more time in case it was just missed: I haven't had to write loop.run_until_complete() for quite some time, as I've been using asynchronous pytest fixtures via pytest-asyncio, which provides the same functionality as these changes and more. This seems like a concern that's separate from aiohttp, IMO.

[asvetlov]

pytest-asyncio is not fully compatible with pytest-aiohttp (while last pytest-asyncio commits has smoothed some corners).

The crucial difference is disabling global event loop by default in pytest-aiohttp.
Another difference is event_loop vs loop fixture name. From my perspective loop is more native: it's used widely by asyncio itself, no event_loop variable in asyncio code.

After asyncio.get_event_loop() fix in Python 3.5.3+ default event loop issue becomes negligible but it's still very important until aiohttp will drop older Python versions support (I hope we'll do it it after next release).

[lock]

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.