Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32k
gh-108828: Support selecting tests by labels#108829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
If possible, I would prefer to land my PR#108858 before. |
2b24913 to5ae7161CompareThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Thanks a lot for working on this, it is definetely a step in the right direction for our test suite.
I have a question about naming, though.
Some tests inLib/test/test_regrtest.py would also be nice, or I can add them later :)
I already have several ideas on top of this PR!
| @@ -498,16 +500,34 @@ The :mod:`test.support` module defines the following functions: | |||
| rather than looking directly in the path directories. | |||
| .. function:: mark(label, *, globals=None) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I would prefer to always call them "marks". The main reason is thatpytest uses the same idea and pytest's marks are well-known.
| ..function::mark(label, *, globals=None) | |
| ..function::mark(name, *, globals=None) |
Right nowmark function adds a "label". It does not sound right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Or we can always call it "label".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yes, it is similar to pytest's markers, but there are enough differences in applying them and filtering by them. I do not have preference, "label", "marker" and "tag" are all look like synonyms in this context to me.
| @@ -498,16 +500,34 @@ The :mod:`test.support` module defines the following functions: | |||
| rather than looking directly in the path directories. | |||
| .. function:: mark(label, *, globals=None) | |||
| Add a label to tests. | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| Add alabel to tests. | |
| Add amark to tests. |
Lib/test/libregrtest/main.py Outdated
| @@ -78,6 +78,14 @@ def __init__(self, ns: Namespace): | |||
| self.ignore_tests: FilterTuple = tuple(ns.ignore_tests) | |||
| else: | |||
| self.ignore_tests = None | |||
| if ns.accept_labels: | |||
| self.accept_labels: tuple[str, ...] = tuple(ns.accept_labels) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Maybeset[str]?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
For some reasons they should be immutable, as well asmatch_tests andignore_tests.
In any case, I am planning to rewrite filtering by names. Instead of two tuples there will be more complex structure where order matters. And the same can be used for labels.
| @@ -1002,16 +1015,41 @@ def wrapper(self): | |||
| #======================================================================= | |||
| # unittest integration. | |||
| def _id(obj): | |||
| return obj | |||
| def mark(label, *, globals=None): | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I had a similar API in one of my OS libs, users didn't like it at all :(
I think it would be better to usemark(..., *, module=False)
This way we can:
- Simplify the API for readers (even if our users are people working on CPython)
- Use
framehack to get the neededglobals()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I do not like to depend on such hack it tests. If it does not work, many unrelated tests will not even be able to load.
Since it is an internal API used in limited number of places, simplicity for users is less important.support.mark('gui', globals=globals()) is not much worse thansupport.mark('gui', module=True)
Uh oh!
There was an error while loading.Please reload this page.