Collect marked functions regardless of naming

[iwanb]

This is just a suggestion, could a function/class be collected if it has a marker attached to it, even if it doesn't follow the function name filter?
I.e. add a ismarkedfunction, similar to the isnosetest, here and in istestclass:
https://github.com/pytest-dev/pytest/blob/master/src/_pytest/python.py#L315

Alternative implementations:

• Change those istestfunction and istestclass methods into a pytest hook instead, so plugins can implement it
• Have a specific marker which would trigger this behavior instead of any marker (that can also be implemented using the hook)

[nicoddemus]

Hi @iwanb,

Thanks for the suggestion!

Personally I'm reluctant to add an alternative to test function collection that differs from what is common practice for years in pytest (and unittest).

Do you have a good use case where the name convention is not good enough?

[iwanb]

It's mainly to avoid duplicating the "test_" (or other) prefix all over the place, which increases the length of the test IDs.

In our case we already use a marker on pretty much all tests to add some metadata, so it's already clear that it's a test case. So I want to implement the third option in a plugin, but it's cumbersome to do currently.

Thinking it over, the second and/or third option is probably the safest, as otherwise the automatic marking of testcases using a module-level pytestmark would have a weird behavior.

Right now I'll probably just monkeypatch the istestfunction method.

[nicoddemus]

In our case we already use a marker on pretty much all tests to add some metadata, so it's already clear that it's a test case. So I want to implement the third option in a plugin, but it's cumbersome to do currently.

I see, thanks for the explanation.

I'm not against adding some hook which would allow this to be customized in a plugin, I still would rather not add an alternative to the pytest core for the above reasons though.

[iwanb]

Ok, I'll make a PR for the hook.

[Zac-HD]

Closing this as stale; I'd still accept a PR for the hook but I don't think we want it so much as to keep an issue around (cf #12465)