GitMate.io thinks possibly related issues are #3346 (Please error when fixtures conflict), #2872 (mark fixtures ), #2399 (marks should propogate through fixtures), #2424 (dynamically generated fixtures), and #3351 (Is there a way to provide mark with fixture params).

@nicoddemus I am starting working on this.

Great, thanks @avirlrma!

@nicoddemus I'm having trouble with code navigation, need some help with it. My initial guess was mark/evaluate.py, but it is called even when there are no marked tests.
I am using a test like below and and setting up breakpoints to find where the @pytest.mark.usefixtures('client') takes me but I'm having no luck with the same.

import pytest

@pytest.fixture
def client():
    print('fixture.client')


@pytest.mark.usefixtures('client')
def test_tom():
    print('user jessie')
    assert 0

Hi @avirlrma,

Actually I believe you need to look at where marks are applied to functions; at that point we need to identify if the function where the mark will be applied is already a fixture (possibly by checking one of the attributes which are attached to the function by the fixture decorator).

(Sorry for the brevity as I'm short on time)

the pytest fixture parser should raise an error if either the fuction or the wrapped function has markers applied

@RonnyPfannschmidt @nicoddemus Where should we catch the error? I mean when fixture is parsed or when the marks are applied to function?

Also,

@pytest.fixture
@pytest.mark.usefixtures('client')
def user_tom():
    print('user jessie')

As far as I understand decorators, mark will applied first, but since then the function is not a fixture, this should work, but it doesn't. Please help me with this as well.

Where should we catch the error?

You mean raise the error? We don't need to catch the error, only raise it to warn the user.

I mean when fixture is parsed or when the marks are applied to function?

Probably at both places, because as you correctly point out, marks and fixtures can be applied in different order.

Btw, perhaps we should issue a warning instead of an error right away?

Ah yes, I meant raise the error.
I am working on finding the code for fixtures are parsed and marks are applied. May need some help on that later.

we should issue a warning instead of an error right away?

How do we do that?

we should check both, fixture, and at fixture parsing time, as we currently still need to catch stuff like

@pytest.mark.usefixtures('client')
@pytest.fixture
def user_tom():
    print('user jessie')

ok, so we have to check both. For now I'm starting with the mark first and then fixture case i.e.:

@pytest.fixture
@pytest.mark.usefixtures('client')

This can be raised when the fixture is parsed, so the necessary changes will be done in fixtures.py . Let me know If you find something wrong with the approach.
Just need explanation on the warning thing @nicoddemus talked about above.