[minor QoL] allow specifying -k multiple times

[jakkdl]

What's the problem this feature will solve?

In projects with lots of parametrized tests across versions, behaviour, etc - or with lots of tests in general - I like to progressively exclude tests while working on features unrelated to those tests to save time on running the test suite. That means I can rack up a series of selected names, especially if working iteratively. Example invocation from my CLI history: pytest -k 'asyncio and normal and noautofix' --no-cov -v -n auto. Stacking on qualifiers currently requires going back and modifying this one text string, and require quoting and the extra and, instead of being able to quickly step back in history and smack on an extra -k. Currently doing pytest -k asyncio -k normal will throw out the first -k and resolve as pytest -k normal.

Describe the solution you'd like

-k to stack, with and, when specified multiple times [on the command line].

Alternative Solutions

Add another flag that achieves the above, such as not to break any current behaviour which might rely on overriding it.

I could also write a CLI function that preparses flags before passing on to pytest proper, in case you deem this too niche to bother with. Relying on plugins, or adding a custom flag to conftest.py would be a no-go as I use this in several different projects and is not something I'd want to commit to random repositories.

[nicoddemus]

I had the same need in the past, and at least to me it seems natural to chain multiple -k flags with and.

This would be a small breaking change however, it would need to be introduced in a major release, with a warning in case users pass multiple -k flags.

[RonnyPfannschmidt]

currently this capability is used to override keywords set in addopts, we need a safe way to deal wit that

[The-Compiler]

Intuitively I'd expect -k test_one -k test_two to combine them with or, just like test_something.py::test_one test_something.py::test_two also runs both tests.

And this (together with breaking existing valid usage) is why I'm -1 on this. I don't think there is a clear intuitive choice between and or or here, and something that works and is used in the wild breaks.

[nicoddemus]

I don't think there is a clear intuitive choice between and or or here, and something that works and is used in the wild breaks.

Agreed.

[jakkdl]

maybe --and and --or as flags? Or --kand and --kor. And if users pass both --and and --or at the same time then either abandon or loudly print how it got interpreted, telling them to use -k.

And if only specifing a single --and/--or it can probably be interpreted as -k.