Document that `mark.usefixtures` does not work on fixtures

[ulope]

I just ran into #378 in a test suite with complex fixture dependencies and it took me quite a while to figure out that usefixtures had no effect when used on fixtures themselves. It would be great if this fact was mentioned in the docs.

[The-Compiler]

This was already documented in #977 - where would you have expected the documentation?

[ulope]

Ah, the problem I see with that is that people probably don't search for mark when they want information on a specific one.

The first hit on google when searching for "pytest usefixtures" leads to https://pytest.org/latest/fixture.html#using-fixtures-from-classes-modules-or-projects. Maybe adding a link to the mark documentation (e.g. "more information on marks and where they're applicable" or some such) would be enough.

[tlandschoff-scale]

I just spent hours on this while refactoring our test suite to reduce duplication between our fixtures (and especially overriding fixtures in different packages). Not knowing that this is a known bug missing feature, I wrote an example to illustrate this:

import pytest

@pytest.fixture
def foo():
    return {"foo": 42}

@pytest.fixture
def bar(foo):
    bar = range(3)
    foo["bar"] = bar
    return bar

@pytest.fixture
@pytest.mark.usefixtures("bar")
def fixture_with_usefixtures(foo):
    return foo

@pytest.fixture
def fixture_using_fixture(foo, bar):
    # bar not used, therefore I'd rather use usefixtures
    return foo

@pytest.mark.usefixtures("bar")
def test_with_usefixtures(foo):
    assert foo["bar"]

def test_indirect_usefixtures(fixture_with_usefixtures):
    assert fixture_with_usefixtures["bar"]

def test_indirect_argument(fixture_using_fixture):
    assert fixture_using_fixture["bar"]

The setup I am testing is a bit complicated. I have a fixture for an IPC broker and another one that creates a client of this broker and attaches it to the broker. Most of the time I actually need the client object but for some tests I only need to have it attached.

Maybe that's not the best way to structure it, but I was very surprised that a fixture can use another fixture in a named parameter but not using the marker.

So my main point is that this is an inconsistency that's easy to fall into.

[nicoddemus]

@tlandschoff-scale agree completely, we should raise some error when that happens, if possible.

[nicoddemus]

And not for usefixtures only, but any mark.

[tlandschoff-scale]

I agree in so far as that is much better than just ignoring the request.
But I don't see any reason why consistency should be avoided here (apart from implementation complexity of course).

You might say that there is no use case of marking a fixture. We already tried that (apart from usefixtures) as well. Basically, we have a large test suite which currently runs an hour but does a lot of integration stuff. Some tests set up an application server or even a network of them (for testing synchronization and caching features).

I actually tried to use @pytest.mark.integration on the fixture that brings up a server as this is generally an expensive operation. I bet this would be useful to other users of pytest as well.

So disallowing this for now is fine with me (as it is not implemented anyway), but I think getting it implemented later should not be definitely ruled out.

[RonnyPfannschmidt]

transfering markers from fixtures should be fine, but quite franckly, with marks as they are now, there is no way

we pretty much have to break some apis to fix it

[nicoddemus]

transfering markers from fixtures should be fine, but quite franckly, with marks as they are now, there is no way

I agree that transferring it is probably possible but there are quirks with marks in general, but my concern is make the rest of the code understand that now fixtures can be marked, including the case mentioned for general marks (@pytest.mark.integration) and parametrization via @pytest.mark.parametrize.

[RonnyPfannschmidt]

@nicoddemus yes, this involves even more transferring markers, and that us currently on a technical base that is at best horrendous and latent broken in many places

[suntzu86]

I just puzzled over this for a while too. Searching docs did not come up with the above warning until I googled for "pytest mark usefixtures not working" which brought me here.

+1 for @nicoddemus 's suggestion at least in the short term. If this had failed loudly, that would have been a lot more clear than silently doing nothing, leaving me wondering how come my code is never called.