Test name id generation defies common sense

What’s the problem this feature will solve?

Make test name generation intuitive and more flexible.

Describe the solution you’d like

Consider the following test cases:

@pytest.mark.parametrize(
    "nums",
    [[3, 1, 5, 4, 2], [2, 6, 4, 3, 1, 5], [1, 5, 6, 4, 3, 2]]
)
def test_cyclic_sort(nums):
    pass


@pytest.mark.parametrize(
    "nums, missing",
    [([4, 0, 3, 1], 2)]
)
def test_find_missing_number(nums, missing):
    pass

I’d like to customize the test names to include the input array only. Even though it’s not mentioned in the docs, turned out that the id func is called once for each argument; so if the same fn is used for both the above tests, for test_cyclic_sort it’d get called with a list, whereas for test_find_missing_number it’d first get called with a list, then with an int. It’s also not possible to ignore the second argument from test_find_missing_number from being part of the test name.

This makes no sense whatsoever. The common sense implementation would be to pass all the args to the id func at once, either as a tuple or sequence. it also would likely be faster than calling the function once for each argument.

Additional context

https://stackoverflow.com/q/66631582/839733

[The-Compiler]

in hindsight the reuse of the ids parameter as both function for single values and list of combined parameter set names was a mistake and should be changed

Agreed. If we agree passing one set of parameters (rather than every parameter individually) at once, that might also be a way forward to change this in a backwards-compatible way, something that @asarkar’s suggestions don’t address so far. Changing ids in a backwards-incompatible way is a no-go IMHO.

the passing of highly customized parameter set id functions seems very problematic as it makes for a tricky inconsistent apis that strongly can differ per usage site.

Can you elaborate? Do you mean for the case where you have a single ID function which you want to reuse across different tests?

I don’t really see the problem - if we had a new idfn argument which takes a set of arguments (rather than a single one), rather than, say:

def get_id(nums, missing):
    return f"{','.join(nums)} missing {missing}"

you could always use a small wrapper like:

def get_id_wrapper(*args):
    return '-'.join(idfn(arg) for arg in args)

to get something very similar to the old behavior. The opposite isn’t possible.

as pytest.param provides the control over the test id per parameterset, i would strongly recommend creating a small helper function that returns a pytest.param with the id you want - it gives greater control and leaves all the complexity of choice exactly at your internal helper

I guess that would work, but I still think there’s value in the lightweight syntax of a

@pytest.mark.parametrize(
    "nums, missing",
    [
        ([4, 0, 3, 1], 2),
        ([5, 6, 8, 9], 7),
    ],
    idfn=get_id
)
def test_find_missing_number(nums, missing):
    pass

rather than:

@pytest.mark.parametrize(
    "nums, missing",
    [
        _param([4, 0, 3, 1], 2),
        _param([5, 6, 8, 9], 7),
    ],
)
def test_find_missing_number(nums, missing):
    pass

---

Also, @asarkar, please dial it down a notch. “defies common sense”, “makes no sense whatsoever”, “is not really an outrageous ask IMO” etc. etc. isn’t very helpful.

[RonnyPfannschmidt]

@asarkar there is line between speaking the truth and being insufferable while speaking the truth, while giving you the benefit of doubt, in my impression you certainly spared no effort to talk down on us and that’s on you

and the CoC certainly has something about needlessly doing that, please check your attitude