Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate an error when a mark is applied to a fixture #3664

Open
nicoddemus opened this Issue Jul 7, 2018 · 13 comments

Comments

Projects
None yet
4 participants
@nicoddemus
Copy link
Member

nicoddemus commented Jul 7, 2018

Follow up from #1014.

We should generate an error if a @pytest.mark is applied to a fixture.

There is a warning in doc/en/fixture.rst about this problem which should be updated once this issue is dealt with.

@pytestbot

This comment has been minimized.

Copy link

pytestbot commented Jul 7, 2018

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).

@avirlrma

This comment has been minimized.

Copy link
Member

avirlrma commented Sep 27, 2018

@nicoddemus I am starting working on this.

@nicoddemus

This comment has been minimized.

Copy link
Member Author

nicoddemus commented Sep 29, 2018

Great, thanks @avirlrma!

@avirlrma avirlrma self-assigned this Oct 4, 2018

@avirlrma

This comment has been minimized.

Copy link
Member

avirlrma commented Oct 4, 2018

@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
@nicoddemus

This comment has been minimized.

Copy link
Member Author

nicoddemus commented Oct 4, 2018

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)

@RonnyPfannschmidt

This comment has been minimized.

Copy link
Member

RonnyPfannschmidt commented Oct 4, 2018

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

@avirlrma

This comment has been minimized.

Copy link
Member

avirlrma commented Oct 4, 2018

@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.

@nicoddemus

This comment has been minimized.

Copy link
Member Author

nicoddemus commented Oct 4, 2018

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?

@avirlrma

This comment has been minimized.

Copy link
Member

avirlrma commented Oct 5, 2018

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?

@RonnyPfannschmidt

This comment has been minimized.

Copy link
Member

RonnyPfannschmidt commented Oct 5, 2018

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')
@avirlrma

This comment has been minimized.

Copy link
Member

avirlrma commented Oct 5, 2018

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.

@nicoddemus

This comment has been minimized.

Copy link
Member Author

nicoddemus commented Oct 5, 2018

Let me know If you find something wrong with the approach.

Sounds good, we can discuss over a PR.

Just need explanation on the warning thing @nicoddemus talked about above.

I mean to issue a warning instead of an error, something like:

warnings.warn(pytest.PytestWarning('marks cannot...'), stacklevel=2)
@avirlrma

This comment has been minimized.

Copy link
Member

avirlrma commented Oct 6, 2018

got it! I'm working on the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.