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

Combining multiple @pytest.mark.parametrize lines #815

Closed
The-Compiler opened this issue Jul 3, 2015 · 6 comments
Closed

Combining multiple @pytest.mark.parametrize lines #815

The-Compiler opened this issue Jul 3, 2015 · 6 comments
Assignees
Labels
topic: parametrize related to @pytest.mark.parametrize type: docs documentation improvement, missing or needing clarification type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@The-Compiler
Copy link
Member

I sometimes write tests something like this:

@pytest.mark.parametrize('foo, bar', itertools.product(['a', 'b', 'c'], [1, 2, 3]))
def test_things(foo, bar):
    ...

to test all combinations of foo and bar. The itertools.product call sometimes gets a bit more complicated which makes this hard to follow.

IMHO, it'd be nicer to be able to write those tests like this:

@pytest.mark.parametrize('foo', ['a', 'b'. 'c'])
@pytest.mark.parametrize('bar', [1, 2, 3])
def test_things(foo, bar):
    ...

And pytest would then generate all possible combinations. What are your thoughts on this?

I'm not sure if the difference between using two args in one parametrize call vs. using two parametrize calls with one argument each is too subtle, though.

@nicoddemus
Copy link
Member

This currently works for me (tested in pytest-2.7.0):

import pytest

@pytest.mark.parametrize('foo', ['a', 'b', 'c'])
@pytest.mark.parametrize('bar', [1, 2, 3])
def test_things(foo, bar):
    assert foo in ['a', 'b', 'c']
    assert bar in [1, 2, 3]
test_foo.py::test_things[1-a] PASSED
test_foo.py::test_things[1-b] PASSED
test_foo.py::test_things[1-c] PASSED
test_foo.py::test_things[2-a] PASSED
test_foo.py::test_things[2-b] PASSED
test_foo.py::test_things[2-c] PASSED
test_foo.py::test_things[3-a] PASSED
test_foo.py::test_things[3-b] PASSED
test_foo.py::test_things[3-c] PASSED

Did you have something else in mind?
(Actually I also didn't know this worked hehehe)

@The-Compiler
Copy link
Member Author

Oh wow, that works indeed! I didn't expect that 😄

I wonder if it's intended or by accident - now the question is if it should be pointed out in the docs, and if there are tests for it.

@nicoddemus
Copy link
Member

Not sure if it's intended, but a PR for the docs would be welcome. 😄

Can we close this then?

@nicoddemus nicoddemus added the type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature label Jul 5, 2015
@The-Compiler
Copy link
Member Author

I want to contribute a PR for docs (and tests, if there aren't any yet) before closing this - though I probably won't have time for that until (or after?) EuroPython.

@The-Compiler The-Compiler self-assigned this Jul 8, 2015
@nicoddemus
Copy link
Member

No problem! 😄

@leimao
Copy link

leimao commented Aug 20, 2020

This currently works for me (tested in pytest-2.7.0):

import pytest

@pytest.mark.parametrize('foo', ['a', 'b', 'c'])
@pytest.mark.parametrize('bar', [1, 2, 3])
def test_things(foo, bar):
    assert foo in ['a', 'b', 'c']
    assert bar in [1, 2, 3]
test_foo.py::test_things[1-a] PASSED
test_foo.py::test_things[1-b] PASSED
test_foo.py::test_things[1-c] PASSED
test_foo.py::test_things[2-a] PASSED
test_foo.py::test_things[2-b] PASSED
test_foo.py::test_things[2-c] PASSED
test_foo.py::test_things[3-a] PASSED
test_foo.py::test_things[3-b] PASSED
test_foo.py::test_things[3-c] PASSED

Did you have something else in mind?
(Actually I also didn't know this worked hehehe)

Thank you.

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: docs documentation improvement, missing or needing clarification 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