DOCS, BUG: Using and clarifying the request fixture.

[PinkShnack]

Hey all,

I have two queries about the request fixture. First one could be a possible documentation change, second is either a bug or my ignorance.

1. I noticed while working with indirect parametrization that the docs assume that the user knows request is a fixture and that it is the only parameter name allowed. I only found this out by reading a stack overflow comment (under accepted answer). Perhaps in the docs here one could state that request is a fixture.

2. Can one cleanly use a fixture for both parametrized and unparametrized tests, if the fixture includes request for use with indirect parametrization? The issue I am having is that I have a fixture that is creating some dummy data, and I want to use this dummy data for simple tests and also parametrized tests. What I reaqlly want I guess is a way to cleanly have request to have a default value. Code example from the pytest docs:

   import pytest
   
   
   @pytest.fixture
   def fixt(request):
       return request.param * 3
   
   
   @pytest.mark.parametrize("fixt", ["a", "b"], indirect=True)
   def test_indirect(fixt):
       assert len(fixt) == 3
   
   
   def test_direct(fixt):  # fails because request.param doesn't exist
       assert len(fixt) == 3

   Traceback:

   test setup failed
   request = <SubRequest 'fixt' for <Function test_direct>>
   
       @pytest.fixture
       def fixt(request):
   >       return request.param * 3
   E       AttributeError: 'SubRequest' object has no attribute 'param'

   My current fix is to add this check to the fixture:

   @pytest.fixture
   def fixt(request):
       if hasattr(request, "param"):
           p = request.param
       else:
           p = "x"  # this is my default value
       return p * 3

pytest and operating system versions

pytest 8.3.4
OS: Microsoft Windows 10

[The-Compiler]

While I'm not opposed to adding a quick note/link to the docs (similarly to what's already done for parametrizing fixtures), I'm also a bit confused: How come that you're looking into indirect parametrization (IMHO one of the most advanced, if not the most advanced, parametrization-related topic), yet haven't come across the request fixture yet?

The "no other parameter name is allowed" thing is an even more basic concept in my eyes, it's simply how all fixtures work in pytest, and the only thing an argument to a fixture function can be is another fixture. I'd expect that kind of previous knowledge when reading about a very advanced topic. I'm not saying this as a criticism, mind you, but I'd really like to understand your perspective on this.

---

As for your second question, I don't think that's a bug. You could simplify your code to p = getattr(request, "param", 3). Alternatively you could parametrize the fixture itself with a single value, but that might be a bit hacky:

import pytest


@pytest.fixture(params=["c"])
def fixt(request):
    return request.param * 3


@pytest.mark.parametrize("fixt", ["a", "b"], indirect=True)
def test_indirect(fixt):
    assert fixt in ["aaa", "bbb"]


def test_direct(fixt):
    assert fixt == "ccc"

[PinkShnack]

Hey, thanks for the quick reply.

How come that you're looking into indirect parametrization

I needed a fixture that I could use in two ways: with a default parameter, and with different parameters. Perhaps there is a much simpler way of doing this.

haven't come across the request fixture yet?

Not sure tbh, I've used parametrization for many tests before, but somehow missed it. I see from your link that request is described clearly: "The fixture function gets access to each parameter through the special request object". I just missed it because I didn't read through the basics while looking into the indirect parametrization. I simply had never thought to parameterize the fixtures themselves (never needed it). To me, fixtures were simply a way to reuse code in a clean way for tests.

I get why you want to know, it's difficult to know how people are reading your documentation.

---

Thanks for the two solutions. Indeed, parametrizing the fixture itself with a default value is probably what I was looking for in the first place. Why would you consider it hacky?

[The-Compiler]

I consider it hacky because there's only a single value, and I'd consider parametrization something that's mostly relevant if you want to run tests multiple times with different values or different objects of some sort.

If all you want is basically passing a value into a fixture (but 0..1 times per test function, not 1..n times), I think the simplest ways are:

• Returning some sort of helper object or a factory function from the fixture, instead of returning the value directly, see Factories as fixtures
• Using a marker on the test case and reading that from the fixture, see Using markers to pass data to fixtures

[PinkShnack]

Great, thank for the detailed answers.

[matteobrv]

Recently I spent quite some time trying to figure out how make Indirect Parametrization work just because I too didn't realize that request is a fixture. I agree that this is already hinted at in the Parametrizing fixtures section. However, this is something that can be easily missed if someone lands directly on the Indirect Parametrization page. I believe that including just a very quick note about this may be beneficial.