Are there any plans on a more sophisticated test case selection approach?

[cswrd]

Selecting testcases with -k, -m and by file_or_dir is rather limited, as they can't be combined in more complex expressions.

Some workarounds I am aware of:

• just run multiple pytest sessions with their own invocations.
• use the new @tests_to_run.txt, potentially created upfront by running multiple pytest --collect-only -q --disable-warnings invocations and redirecting their ouputs in a file.
• use the pytest-regex extension.

All have their own own drawbacks.

Are there any plans on a query language like selection or similar?

[RonnyPfannschmidt]

There's been a few discussions, however it's very easy to mess up with such languages and we never assembled n a fit capacity to expand upon what we learned from the the non python marker expression language

[cswrd]

I understand, it's a non trivial feature. What do you mean by the "non python marker expression language"?

[RonnyPfannschmidt]

For ages marker expressions and keyword expressions used python syntax, these days they have a custom parser that offers more matching syntax for edge cases like bracket's

[The-Compiler]

Can you elaborate a bit on your use case for this? Do you want to combine different "kinds" of selectors here, as in saying "tests that are either in test_spam.py or which have the eggs marker"?

[cswrd]

Yes, exactly like that. Tests of in the pkg tests.foo and the marker fast + tests in the package tests.bar with the markers foobar and barfoo and the keywords api or rest and so on.

Right now, I use the 2nd approach mentioned in my original post. It provides quite powerful test selection capababilites and the tests run in 1 session.

side note: I'd appreciate some more information on the general topic specifying which tests to run. A link to the -k cli arg docs would be really helpful there. How many arguments for -k and -m are allowed and how are they are combined (AND / OR)? I usually go for the trial-and-error approach to figure out the exact behaviour. Also the file based approach is a little vague on how the elements are combined there. Afaik a -m marker applies to all tests in that file, right? Because in my approach the input might look exactly the same, but each line would go through there own pytest collection cycle. Thus, a -m would not limit the test cases mentioned above, but just add all tests with that marker.