Add support for coroutine-based concurrency
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.
Basic illustration
Suppose we have the following abstract code:
async def f():
with change_global_state():
await long_io_operation()
async def g():
use_global_state()
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:
import asyncio
async def execute_all():
await asyncio.gather(f(), g())
asyncio.run(execute_all())
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:
import pytest
import allure
import asyncio
@pytest.mark.asyncio
async def test_with_concurrent_steps():
fence = asyncio.Event()
async def run_with_step(name):
with allure.step(name):
await fence.wait()
async def release_fence():
fence.set()
await asyncio.gather(
run_with_step("Step 1"),
run_with_step("Step 2"),
release_fence()
)
Note: the steps could've been executed with asyncio's create_task function instead with the same effect.
The following *result.json is generated (most unrelated fields are omitted):
{
"name": "test_with_concurrent_steps",
"status": "passed",
"steps": [{
"name": "Step 1",
"status": "passed",
"steps": [{
"name": "Step 2",
"status": "passed"
}]
}]
}
And it is shown in the report like this:

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:
import pytest
import allure
import asyncio
@pytest.mark.asyncio
async def test_with_concurrent_steps():
fence = asyncio.Event()
async def run_with_step(name):
with allure.step(name):
await fence.wait()
async def release_fence():
fence.set()
await release_fence()
await run_with_step("Step 1")
await run_with_step("Step 2")
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.
Is there anymore movement on this?
I have spent days trying to workaround this issue, and the only solution I've been able to do is comment out 1000s of allure steps in our testing project.
Your last comment... Python 3.7 is EOL and 3.8 become EOL in October.
I think a breaking change version or only supporting async in newer versions is ok.
@delatrie
Hi! Is there any solution for this problem? I'm using python 3.13 in my project and allure-pytest 2.13.5 and have the same problem. Steps inside asyncio.gather() are nest each other instead of been independent.
Is there any progress for this problem? I have a problem just like Scenario 2, code run ok, but the allure step is nested, which is hard to read.
@delatrie hi, please tell me if this problem is going to be solved or if we should not wait.