Pre-PR for warnings on unknown markers#5015
Conversation
Zac-HD
force-pushed
the
mark-warning-prep
branch
from
44f4068 to
00810b9
Compare
Codecov Report
@@ Coverage Diff @@
## features #5015 +/- ##
============================================
+ Coverage 96.06% 96.06% +<.01%
============================================
Files 114 114
Lines 25749 25750 +1
Branches 2548 2548
============================================
+ Hits 24735 24736 +1
Misses 704 704
Partials 310 310
Continue to review full report at Codecov.
|
| default:invalid escape sequence:DeprecationWarning | ||
| pytester_example_dir = testing/example_scripts | ||
| markers = | ||
| issue |
There was a problem hiding this comment.
We're already using issue, so I'd rather leave any changes to a future PR and just standardise here.
There was a problem hiding this comment.
Well, a) I do not know how this is used actually, but b) you're touching all those lines already (and therefore it would be good to do it right away).
There was a problem hiding this comment.
We're already using issue, so I'd rather leave any changes to a future PR and just standardise here.
I never used it myself. I think we can actually remove them in the future, unless someone steps up and mentions he/she uses it on their workflow.
Co-Authored-By: Zac-HD <Zac-HD@users.noreply.github.com>
|
|
||
| This can be used to prevent users mistyping mark names by accident. Test suites that want to enforce this | ||
| should add ``--strict`` to ``addopts``: | ||
| When the ``--strict`` command-line flag is passed, any unknown marks applied |
There was a problem hiding this comment.
@Zac-HD how about using this PR and add --strict-marks as an alias to --strict, while also updating the docs to use the former?
There was a problem hiding this comment.
I'd prefer to leave functional changes to the other PR - will discuss there.
3 participants
This pull request is designed to make #4935 much smaller and easier to work on (or review). The four commits each make a helpful change that is also worth doing independently.
pytesterwas using an unregistered marker - adding it to the help is both useful for users and will avoid making usage a warning later.--strictand marks.mark.issueandmark.issueNNN; standardising on the former makes selecting issue-relevant tests uniform - and means we won't need to register every number.I'm targeting
featuresso that I can rebase #4935 as soon as this is merged 😄