What's the problem this feature will solve?
I find myself writing many highly-parametrized tests. One of the pain-points arises when supplying an array of test IDs for a long array of cases in argvalues.
Describe the solution you'd like
One of the ways I work around this is by building a dictionary like so (a trivial example):
test_matrix = dict(
foo_is_not_bar=("foo", "bar")
)
@pytest.mark.parametrize(
argnames="input,negation"
argvalues=test_matrix.values()
ids=test_matrix.keys()
)
def test_negation(input, negation):
assert input != negation
A real-world example:
https://github.com/seandstewart/typical/blob/5c609a0091c2500319cf714e3f86e907db8c717f/tests/ext/schema/test_json_schema.py#L41-L413
As you can see, the more cases we try to pass through a parametrized test, the further the test matrix gets from the test definition.
Alternative Solutions
Use Parametrized Fixture(s)
This could also be implemented via a parametrized fixture, but has the same drawback of isolating the test case from from test definition, so it becomes difficult to understand a test from a single look.
Additional context
Essentially, I'm looking for a way to define my test inputs and IDs in a unified manner, as close to the test definition as possible. I think the ability to define these as an object which I pass to parametrize(...) makes sense, but I'm open to alternatives.
What's the problem this feature will solve?
I find myself writing many highly-parametrized tests. One of the pain-points arises when supplying an array of test IDs for a long array of cases in
argvalues.Describe the solution you'd like
One of the ways I work around this is by building a dictionary like so (a trivial example):
A real-world example:
https://github.com/seandstewart/typical/blob/5c609a0091c2500319cf714e3f86e907db8c717f/tests/ext/schema/test_json_schema.py#L41-L413
As you can see, the more cases we try to pass through a parametrized test, the further the test matrix gets from the test definition.
Alternative Solutions
Use Parametrized Fixture(s)
This could also be implemented via a parametrized fixture, but has the same drawback of isolating the test case from from test definition, so it becomes difficult to understand a test from a single look.
Additional context
Essentially, I'm looking for a way to define my test inputs and IDs in a unified manner, as close to the test definition as possible. I think the ability to define these as an object which I pass to
parametrize(...)makes sense, but I'm open to alternatives.