Skip to content

marks should propogate through fixtures #2399

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

Closed
majuscule opened this issue May 10, 2017 · 5 comments
Closed

marks should propogate through fixtures #2399

majuscule opened this issue May 10, 2017 · 5 comments
Labels
topic: marks related to marks, either the general marks or builtin type: enhancement new feature or API change, should be merged into features branch type: feature-branch new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@majuscule
Copy link

majuscule commented May 10, 2017

Example code below. Expected output: passing tests. Actual output, AssertionError.

import pytest

@pytest.fixture(scope='function', autouse=True)
def db_rollback(request):
    assert request.node.get_marker('db_rollback_exempt')

@pytest.fixture(scope='function')
@pytest.mark.db_rollback_exempt
def context():
    return True

def test_foo(context):
    assert True
@RonnyPfannschmidt
Copy link
Member

in #977 we already documented that this doesn't work

there are 2 problems keeping it that way
a) in any more complex fixture setup its completely unclear in what way to propagate marks, nobody sat down and made a reasonably complete proposal (that includes parametrisation)
b) the current implementation of marks and mark propagation is completely misfit for such a feature and would need a relatively large restructuring/rewrite

@nicoddemus
Copy link
Member

Should we close this then, or keep it open for reference?

@RonnyPfannschmidt
Copy link
Member

@nicoddemus i'd like to decide after feedback from @majuscule

@majuscule
Copy link
Author

Hi @RonnyPfannschmidt, @nicoddemus, thanks for the quick response. I'd like to keep this open as a feature request. Can you give an example of a complex fixture design (possibly with parametrization) that makes this difficult? I'm thinking that a mark should simply be inherited by any function that the marked fixture is provided to.

@RonnyPfannschmidt RonnyPfannschmidt added type: feature-branch new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature topic: marks related to marks, either the general marks or builtin labels May 11, 2017
@RonnyPfannschmidt
Copy link
Member

oh, also im closing thos one as a duplicate of #1368

@nicoddemus nicoddemus added type: enhancement new feature or API change, should be merged into features branch and removed type: enhancement new feature or API change, should be merged into features branch labels Sep 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: marks related to marks, either the general marks or builtin type: enhancement new feature or API change, should be merged into features branch type: feature-branch new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

3 participants