Currently, we don`t support running allure-python in an async function (e.g. through asyncio event loop or a similar coroutine execution engine).
This is important, because
Async-based frameworks and libraries are growing in popularity (aiohttp, aiofile, aiopg, etc.), so we need to support testing asynchronous code
E2E tests are heavily IO-bound. The ability to run them concurrently may improve tests performance significantly.
Coroutines and contexts
A coroutine in python is created with a coroutine declaration, i.e. a function with the async keyword. Inside a function the await keyword can be used to wait for an asynchronous operation to complete. A coroutine execution engine can then pause the coroutine and resume execution of another one, increasing performance of IO-bound computations.
Without proper means a coroutine paused inside a context manager may leak unintended global state into another coroutine.
If we create two coroutines (one with f() and the other one with g()) and schedule both coroutines for execution, it is possible that g will use the state, not expected to be visible outside f.
Below is an example, how both coroutines could be run with asyncio:
There are two general scenarios we can face while generating allure report. They are described below.
Scenario 1: running multiple tests concurrently
This scenario requires a pytest plugin capable of executing async tests concurrently, like pytest-asyncio-cooperative. Unfortunately, this particular plugin currently doesn`t work with allure-pytest, so the remaining content in this section describes more of a theoretical case, as if the plugin actually works.
If we assume the plugin works, the test may looks like this (also, see here):
import allure
import asyncio
import pytest
@pytest.fixture(scope="session")
async def fence():
yield asyncio.Event()
@pytest.mark.asyncio_cooperative
async def test_with_async_operation(fence):
with allure.step("Wait for a fence"):
await fence.wait()
@pytest.mark.asyncio_cooperative
async def test_without_async_operation(fence):
with allure.step("Setting a fence"):
fence.set()
After test_with_async_operation is paused, the event loop starts executing test_without_async_operation. The step "Setting a fence" is created inside the "Wait for a fence"" step context, emitting an invalid test result: the first test result contains two nested steps instead of one, while the second one contains no steps whatsoever.
Scenario 2: running multiple steps concurrently inside one test
This one is easily achieved either with a self-written fixture, or with pytest-asyncio.
Given we have pytest-asyncio installed and the following code:
We probably should utilize ContextVars, they were introduced for the very this issue (see PEP567). Cons: they require python 3.7. If we decide to move this way, we may either declare async concurrency supported in python 3.7+ only or drop python 3.6 support completely (our latest decision was to focus on 3.7+ while trying to stay 3.6-compatible, if possible).
Currently, we don`t support running allure-python in an async function (e.g. through asyncio event loop or a similar coroutine execution engine).
This is important, because
aiohttp
,aiofile
,aiopg
, etc.), so we need to support testing asynchronous codeCoroutines and contexts
A coroutine in python is created with a coroutine declaration, i.e. a function with the
async
keyword. Inside a function theawait
keyword can be used to wait for an asynchronous operation to complete. A coroutine execution engine can then pause the coroutine and resume execution of another one, increasing performance of IO-bound computations.Without proper means a coroutine paused inside a context manager may leak unintended global state into another coroutine.
Basic illustration
Suppose we have the following abstract code:
If we create two coroutines (one with
f()
and the other one withg()
) and schedule both coroutines for execution, it is possible thatg
will use the state, not expected to be visible outsidef
.Below is an example, how both coroutines could be run with
asyncio
:There are two general scenarios we can face while generating allure report. They are described below.
Scenario 1: running multiple tests concurrently
This scenario requires a pytest plugin capable of executing async tests concurrently, like pytest-asyncio-cooperative. Unfortunately, this particular plugin currently doesn`t work with allure-pytest, so the remaining content in this section describes more of a theoretical case, as if the plugin actually works.
If we assume the plugin works, the test may looks like this (also, see here):
After
test_with_async_operation
is paused, the event loop starts executingtest_without_async_operation
. The step"Setting a fence"
is created inside the"Wait for a fence""
step context, emitting an invalid test result: the first test result contains two nested steps instead of one, while the second one contains no steps whatsoever.Scenario 2: running multiple steps concurrently inside one test
This one is easily achieved either with a self-written fixture, or with pytest-asyncio.
Given we have pytest-asyncio installed and the following code:
Note: the steps could've been executed with
asyncio
'screate_task
function instead with the same effect.The following
*result.json
is generated (most unrelated fields are omitted):And it is shown in the report like this:![image](https://user-images.githubusercontent.com/17935127/208509785-7a1f1e10-78cd-4bf7-aecc-b7a1e7bc6820.png)
The steps are nested one into another instead of being independent as was intended.
Workaround
To fix the report, change you code so the functions that create steps are executed synchronously:
The downside is slower execution and the need to rewrite the logic in your code.
Also, see this test.
Thought on possible implementation
We probably should utilize ContextVars, they were introduced for the very this issue (see PEP567). Cons: they require python 3.7. If we decide to move this way, we may either declare async concurrency supported in python 3.7+ only or drop python 3.6 support completely (our latest decision was to focus on 3.7+ while trying to stay 3.6-compatible, if possible).
Can`t think of another possible way for now.