Pytest: Marks vs tags

[Sup3rGeo]

Hi guys,

I am working in the allure-pytest plugin, and I think that pytest.mark.xxx is actually dealing with two different concepts.

One of them being the concept of tags, which are basically simple labels we are placing on the test, the goal being to use it later on to classify/select based on this. That is the case for pytest.mark.something, without any explicit call.

The other one is more implementation related, where marks are just some sort of attribute attached to a specific test (or derived from classes to tests) that pytest uses to implement some custom logic. In this category I would include skip, skipif, parametrize, use_fixture and others.

Correct if I am wrong, but we would never use pytest -m in any marks that are calls (second category)?

I would like to clarify this not to ask for any changes in pytest, but to know if it is correct to consider as "tags" in the report only the first category ("dumb" marks).

Thanks!

[RonnyPfannschmidt]

@Sup3rGeo marks are Frankenstein monsters that started as somefunction.__dict__.update - and then evolved towards supporting arbitrary arguments

recently we did a intense cleanup, so now all marks are actual named markers with potentially empty argument set, but we still provide some old api

the marker expressions pretend all mark names are "tags"

so pytest -m will use any marker, no matter whether it had arguments or not

[laurentbristiel]

This terminology of "marker" is one of the few thing that I found a bit confusing at first. I was expecting the word "tag" to be used. And in SO, people are writing things like "In pytest you can mark a test case with a tag"... But well, I guess you can live with that :-)

[RonnyPfannschmidt]

@laurentbristiel for all means and purposes - the markers where never "tags"

[nicoddemus]

@Sup3rGeo can we close this?

[Sup3rGeo]

I would just like hear if someone is using pytest -m for markers other than the no-args ones (pytest.mark.xxx).

Also, is pytest.mark.marker(param1=arg1, param2=arg2 ...) is still supported? What would be a use case for it? We have it on allure-pytest so I don't know if it is safe to remove support for it.

@nicoddemus if no one says anything in a few days then we can close it.

[RonnyPfannschmidt]

@Sup3rGeo -m acts on all markers - but can only "attest" to existence

[Sup3rGeo]

@RonnyPfannschmidt I understood that (and nice to learn that it is checking for existence only), but just would like to know if people were really using pytest -m skip/use_fixtures/xfail or something like that in day-to-day usage.

Because I feel it would make sense in terms of user experience that parametrize, xfail, an others not be marks. And leave marks only for the sole purpose of being selectable by -m.
The consequence would be of course you cannot really select with -m for parametrize and xfail.

@pytest.xfail()
def function1():
    pass

@pytest.parametrize( )
def function2():
    pass

[RonnyPfannschmidt]

@Sup3rGeo i would expect not at all - but as is - parameterize, xfail and co are marks

marks in general are designed and layered in a very sloppy foggy way due their history - its pretty much an completely unfixable issue by now

[nicoddemus]

if people were really using pytest -m skip/use_fixtures/xfail or something like that in day-to-day usage.

Oh I see. Well in my experience people use -m for marks which don't accept parameters, FWIW. 👍

[Sup3rGeo]

So closing this one given all the information here, thank you very much guys!