-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Add --minimal-messages-config
option for functional tests
#6246
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --minimal-messages-config
option for functional tests
#6246
Conversation
Pull Request Test Coverage Report for Build 2172399998
💛 - Coveralls |
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.
Imo this is a pretty great tool to find issues with 'check_message'. We could even add one job for it in continuous integration if we add a "expected to fail" list.
We can expand This way we could integrate this check in the CI right away, probably directly with this PR. |
I added the test file option. |
… false negatives
…` run. Have to find out how the list of deprecated modules is built first.
Thanks for working on this @DudeNr33! |
…DudeNr33/pylint into functional-tests-enable-disable
…DudeNr33/pylint into functional-tests-enable-disable
…ffects TokenChecker/RawChecker
…ing depends on what messages are enabled.
… is ``False`` when enabling just this message.
… triggered too often in this case.
…-messages-config``
This should be ready for review now. Most fixes were trivial.
|
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.
This is a pretty great addition to our test suite. I'm wondering where exactly we're going to launch it as I don't see a new job in the CI for it ?
@@ -1,2 +1,5 @@ | |||
[typing] | |||
py-version=3.6 | |||
|
|||
[testoptions] | |||
exclude_from_minimal_messages_config=true |
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.
Just wondering, should we do this the other way around: allowing certain tests to be "optimised" by this option? Or would that be too much work?
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.
No, I would leave it this way:
This check makes (imo) a lot of sense, and it should be enabled by default (once we found a suitable place for it in the CI).
Being able to check for just a single message explicitly is not an optimisation for me, but part of "correct functional behaviour". Doing this is even mentioned in our docs.
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.
Just to be sure, we're also testing that the message is emitted when everything is activated like we did before ?
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. This option is not enabled by default. Right now, the CI doesn't use it in any way yet.
We should add a separate test job for it, because testing for false positives could be tricky if we made this the default behavior.
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.
That's why I wonder if we should make this opt-in instead of opt-out. That way we can just enable this in the general CI job and opt tests in whenever we want to?
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 think the default use of pylint is to check all messages so opt out is the best way to add --minimal-message-config imo.
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.
Daniel, maybe we are talking about different things?
Right now, all test runs will behave exactly the same as before. Only if you run pytest --minimal-messages-config tests/test_functional.py
, all messages except the ones which are checked by the test are disabled.
Ideally, one day we can run all of the functional tests once with all messages enabled and once with only the specific message enabled. This way we can check both: undesired side effects from code executed for other messages, and undesired side effects due to code not being run because messages are disabled.
Both could lead to bugs.
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.
Hm okay. Yeah I was thinking of one day running just once with this flag enabled, but the way you put it it might actually be better to do both. Then this system is fine!
Co-authored-by: Pierre Sassoulas <[email protected]>
doc/whatsnew/<current release.rst>
.and preferred name in
script/.contributors_aliases.json
Type of Changes
Description
Inspired by @DanielNoord's approach in
test_messages_documentation.py
.This should be our best friend in finding false negatives due to wrong usage of
@check_messages
.I added a
pytest
option called--minimal-messages-config
. If enabled, all messages that are not explicitly defined as expected with the# [<msgid>]
syntax are disabled.However, we can't (yet) make this the default behaviour, even if we fixed all
@check_messages
decorators:abstract_abc_methods.py
for example.@check_messages
decorators another root cause for false negatives are cases where a checker class reuses a message of another checker class.I ran the functional tests and ended up with 32 errors (vs ~700 passing tests, so it's not that bad).
Ref #6060