Skip to content

marks should propogate through fixtures #2399

Closed

Description

@majuscule

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

Activity

  1. RonnyPfannschmidt commented on May 10, 2017

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

  2. nicoddemus commented on May 10, 2017

    @nicoddemus
    Member

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

  3. RonnyPfannschmidt commented on May 10, 2017

    @RonnyPfannschmidt
    Member

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

  4. majuscule commented on May 10, 2017

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

  5. added
    type: feature-branchnew feature or API change, should be merged into features branch
    type: proposalproposal for a new feature, often to gather opinions or design the API around the new feature
    topic: marksrelated to marks, either the general marks or builtin
    on May 11, 2017
  6. RonnyPfannschmidt commented on May 14, 2017

    @RonnyPfannschmidt
    Member

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

  7. added
    type: enhancementnew feature or API change, should be merged into features branch
    and removed
    type: enhancementnew feature or API change, should be merged into features branch
    on Sep 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic: marksrelated to marks, either the general marks or builtintype: enhancementnew feature or API change, should be merged into features branchtype: feature-branchnew feature or API change, should be merged into features branchtype: proposalproposal for a new feature, often to gather opinions or design the API around the new feature

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions