Question: Can the parametrization separator be changed?

[liiight]

Is it possible to change the parameterization separator from dash to another char? Couldn't find the answer, I apologize if it exist.

On a side note, I've been a pytest user both professionally and in open source capacity for years now, and I absolutely love it. You guys created an icon in the software development world.

[pytestbot]

GitMate.io thinks possibly related issues are #3273 (Question: How can I parameterize my tests with global variable which changes values on runtime.), #3601 ((question) Cleaning up from parameter generation), #249 (document and/or change display of parametrization values in IDs), #531 (Problems with fixture parametrization), and #3320 ([question] Multithreaded support in a function).

[RonnyPfannschmidt]

currently the dash is hardcoded, can you outline your use-case?

[liiight]

Test names are the source of several reports I use, trying to make it a little more readable. Hardly a major issue.

I could try to do this myself if you guys think there's merit to it, been wanting to contribute to pytest directly.

Maybe pytest_parameterization_seperator hook?

[RonnyPfannschmidt]

at first glance this reads like a feature that doesnt add the value that justifies the extra complexity needed

[liiight]

Well, not having a clue about the added complexity I cannot comment on that, but I believe that any ability to customize the visibility of the results can be very useful.

If you do decide to deem this issue as worthy, I'd be happy to take a stab at it.

[DanaGoyette]

I'd also like to be able to change the separator. In my framework, I'm having to monkeypatch pytest, so I can get commas instead of dashes.

Example of a test name before:

test_snmp_get[2c-master-master]
test_snmp_get[2c-subagent-slave]

Add in a pytest_make_parametrize_id that returns '<argname>=<val>':

test_snmp_get[version=2c-mode=master-zone=master]
test_snmp_get[version=2c-mode=subagent-zone=slave]

To me, that name looks like version = 2c-mode = subagent-zone = slave.
I'd say dashes/hyphens are meant for joining things, not for separating them, and now I'm reminded of an XKCD comic ("hyphen").

After monkey-patching pytest to use commas:

test_snmp_get[2c,master,master]
test_snmp_get[2c,subagent,slave]

Re-add the pytest_make_parametrize_id:

test_snmp_get[version=2c,mode=master,zone=master]
test_snmp_get[version=2c,mode=subagent,zone=slave]

Example monkey-patch, on pytest 3.6.1:

    def id(self):
        """
        Original version joined parameters with dashes, which is weird.
        Given arguments arg1=a, arg2=x:
        Before: "test_name[a-x]"
        After: "test_name[a,x]"
        """
        return ','.join(map(str, filter(None, self._idlist)))

    # Replace the property function itself.
    setattr(_pytest.python.CallSpec2, 'id', property(id))

    def _idvalset(idx, parameterset, argnames, idfn, ids, config=None):
        from _pytest.compat import ascii_escaped
        from _pytest.python import _idval
        if parameterset.id is not None:
            return parameterset.id
        if ids is None or (idx >= len(ids) or ids[idx] is None):
            this_id = [_idval(val, argname, idx, idfn, config)
                       for val, argname in zip(parameterset.values, argnames)]
            return ",".join(this_id)
        else:
            return ascii_escaped(ids[idx])

    _pytest.python._idvalset = _idvalset

[nicoddemus]

I share @RonnyPfannschmidt's worry about increasing pytest's code complexity, but seems CallSpec and _idvalset have access to the config object so it might not get so complex at the end.

We have a pytest_make_parametrize_id hook, perhaps @liiight suggestion of having another hook for the separator would be a good approach.

An ini option has two problems:

• this seems rare enough to be a another option to users (in an ever expanding list)
• this is not something you want users to fiddle with in the command-line (with -o) given that this changes test ids and this affects other plugins (like cache with --lf options).

[DanaGoyette]

I also realize that I don't remember why I monkey-patched both of those functions. I'd imagine the two are used in different places, but I don't recall precisely where for each.

[RonnyPfannschmidt]

since iths is about reporting why do we think about making the internals more complex instead allowing more information for reporting - neither reporting nor the internals are well served by a hook to make the ids dynamic in that particular way

[nicoddemus]

instead allowing more information for reporting

It is not clear what you mean here @RonnyPfannschmidt, could you please clarify this a bit? I think you are on to something here.

[RonnyPfannschmidt]

Stuff like exposing parameter values in a mapping that people can use

[nicoddemus]

I see, for example a mapping on the Item itself with the parametrized parameters for that item?

I see where you are getting at, you are absolutely right.

[DanaGoyette]

The test IDs themselves are used in the TerminalReporter and in Junit reporting, so if we don't change the actual test IDs, we'll need ways to customize every single plugin that uses test IDs.

An alternate approach, if a hook is too complicated: move the separator character into a documented attribute of the Config object. Perhaps you could allow overriding at the instance level, by defining it as a class attribute and then accessing it via self?

[Zac-HD]

Closing this as inactive / wontfix: while it's certainly useful in some cases, it has tricky interactions with enough other functionality (including plugins) that the overall impact seems negative 😢

[cohml]

This issue's status as completed implies this feature was implemented, but @Zac-HD's final comment suggests it was not.

What is the status of this feature currently? I too would find it useful, albeit not critical.

[The-Compiler]

@cohml FWIW, the distinction between closing an issue as "completed" and "not planned" was only added to GitHub in mid 2022. Any issue closed before that will be closed as "completed", and you'll need to look at the comment (as above) or labels to figure out why.

[cohml]

Good to know - TIL!