`pytest_asyncio_loop_factories` hook is not called when `pytest.mark.asyncio` is added via parametrization

[francis-clairicia]

Description

If pytest.mark.asyncio is added via parametrization (pytest.mark.parametrize() or pytest.fixture(params=...)), the test functions ignores the configured loop factories.

Steps to reproduce

In conftest.py:

from typing import Any
import uvloop


def pytest_asyncio_loop_factories() -> dict[str, Any]:
    return {"uvloop": uvloop.new_event_loop}

In test_async.py:

import asyncio
import uvloop
import pytest
import trio


@pytest.mark.parametrize(
    "backend",
    [
        pytest.param("asyncio", marks=pytest.mark.asyncio),
        pytest.param("trio", marks=pytest.mark.trio),  # <- Come from pytest-trio
    ]
)
async def test_async(backend: str) -> None:
    match backend:
        case "asyncio":
            assert isinstance(asyncio.get_running_loop(), uvloop.Loop)
        case "trio":
            assert trio.lowlevel.current_root_task() is not None

Expected the runner to be uvloop.Loop but it uses the default loop.

Workaround

There is a workaround possible to avoid the issue by using the test inheritance:

import asyncio
import uvloop
import pytest
import trio


class _BaseTestAsync:

    async def test_async(self, backend: str) -> None:
        match backend:
            case "asyncio":
                assert isinstance(asyncio.get_running_loop(), uvloop.Loop)
            case "trio":
                assert trio.lowlevel.current_root_task() is not None


@pytest.mark.asyncio
class TestAsyncIO(_BaseTestAsync):

    @pytest.fixture
    @staticmethod
    def backend() -> str:
        return "asyncio"

@pytest.mark.trio
class TestTrio(_BaseTestAsync):

    @pytest.fixture
    @staticmethod
    def backend() -> str:
        return "trio"

But compared to fixture parametrization, it is a bit complicated.

Use case

I have a project which must run with asyncio and trio but do not rely on anyio, therefore I use the fixture parametrization to test on all supported runners.

[tjkuson]

Thanks for the report. This looks like a bug, and I can reproduce it locally with pytest-asyncio v1.4.0.

Under strict mode, pytest-asyncio uses the presence of pytest.mark.asyncio to determine which tests it owns. Loop-factory selection is then driven via parametrization, so the problem arises when the marker that triggers it is itself a product of parametrization: at the point we'd parametrize the loop factory, the marker only exists on individual parameter sets, not on the test under inspection.

Unfortunately, we're limited by pytest itself, which lacks a public API for partial or dependent parametrization. In the example you posted, this means we can't cleanly drive test_async for the asyncio backend without also affecting the trio path (at least not without hacking pytest internals).

There's an open pytest issue for exactly this (pytest-dev/pytest#13233), and an open PR that would, if I follow correctly, give us the public API needed to implement a clean fix (pytest-dev/pytest#13242). However, it hasn't seen activity in over a year.

In the meantime, I'd suggest the following as a more ergonomic workaround.

async def _check_backend(backend: str) -> None:
    match backend:
        case "asyncio":
            assert isinstance(asyncio.get_running_loop(), uvloop.Loop)
        case "trio":
            assert trio.lowlevel.current_root_task() is not None


@pytest.mark.asyncio
async def test_asyncio() -> None:
    await _check_backend("asyncio")


@pytest.mark.trio
async def test_trio() -> None:
    await _check_backend("trio")