Skip to content

parameterize argvalues with a mapping #3588

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
ikonst opened this issue Jun 16, 2018 · 6 comments
Closed

parameterize argvalues with a mapping #3588

ikonst opened this issue Jun 16, 2018 · 6 comments
Labels
topic: parametrize related to @pytest.mark.parametrize type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@ikonst
Copy link
Contributor

ikonst commented Jun 16, 2018

The current syntax for providing an id along with a parameter set is:

@pytest.mark.parameterize('a,b', [
    pytest.param(1, 3, id='odds'),
    pytest.param(2, 4, id='evens'),
])
def test_something(a, b):
    ...

I'd like to get peoples' opinions about an alternative syntax:

@pytest.mark.parameterize('a,b', {
    'odds': (1, 3),
    'evens': (2, 4),
})
def test_something(a, b):
    ...

The rationale, other than the alternative being shorter, is that (it seems to me) that mappings are natural for pairing identifiers and data. If we have to decide on a way to interpret someone passing a mapping into argvalues, I think that'll be a natural one.

P.S. currently, if you pass a dictionary as argvalues, its keys are iterated and the values are discarded

@pytestbot
Copy link
Contributor

GitMate.io thinks possibly related issues are #3196 (How to parameterize the entire test suite?), #1263 (mapping the fixture parameter with the test method parameter), #120 (py.test.mark.parameterize works with test functions, but not classes), and #423 (Consecutive pytest.mark.skipif inside pytest.mark.parameterize).

@nicoddemus
Copy link
Member

Hi @ikonst,

Thanks for writing!

I like the idea, but I'm -1 on adding yet another way to parametrize values, as we would still need to keep the old ways working.

@nicoddemus nicoddemus added type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature topic: parametrize related to @pytest.mark.parametrize labels Jun 16, 2018
@RonnyPfannschmidt
Copy link
Member

this was proposed before and rejected

@nicoddemus
Copy link
Member

I see, let's close this then. Once again thanks @ikonst for the suggestion!

@ikonst
Copy link
Contributor Author

ikonst commented Jun 16, 2018

Do you remember what was the rationale for rejection before? “yet another”?

@RonnyPfannschmidt
Copy link
Member

@ikonst it couldn't sanely support features like adding markers to certain calls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: parametrize related to @pytest.mark.parametrize 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

4 participants