-
Notifications
You must be signed in to change notification settings - Fork 17
Description
Thanks for your library, it's very helpful!
Rule request
When writing parametrized tests, I've seen the case where one wants to test against a matrix of inputs, and thus duplicates some of the entries in the test cases (but not a perfect duplicate, since that's already detected.
Description
Example of bad code:
@pytest.mark.parametrize(
("settings", "environment"),
[
(None, "production"),
({}, "production"),
({"my settings": "value"}, "production"),
(None, "development"),
({}, "development"),
({"my settings": "value"}, "development"),
],
)
def test_matrix(settings, environment):
...An example of a better way:
@pytest.mark.parametrize(
"settings",
[
None,
{},
{"my settings": "value"},
],
)
@pytest.mark.parametrize(
"environment",
[
"production",
"development",
],
)
def test_matrix(settings, environment):
...Rationale
The test cases are expressing ("settings" * "environment") == 6 test cases.
Adding another setting or environment leads to needing to recall to add N settings cases per environment, or vice versa, which we may forget.
Using stacked parametrized marks allows us to only add the new entry once, and the collection phase to expand those to the correct amount of distinct test cases instead of having to ensure that every permutation is expressed.
I'm not sure how hard it is to detect duplicate test cases, but maybe this can reuse some of that logic?