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
Fix: Make rule-tester strictly check messageId. (ref #9890) #9908
Fix: Make rule-tester strictly check messageId. (ref #9890) #9908
Conversation
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 one small message suggestion, otherwise this looks good to me. (N.B. I still need to check to make sure this does what we agreed on in the issue.)
lib/testers/rule-tester.js
Outdated
assert.strictEqual( | ||
error.messageId, | ||
message.messageId, | ||
`messageId mismatch saw '${message.messageId}' and expected '${error.messageId}'.` |
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 message feels like a run-on sentence. I would suggest something like:
messageId '${message.messageId}' does not match expected messageId '${error.messageId}'.
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.
👍 Will do.
9ca36d8
to
fa2ca54
Compare
@platinumazure The code now aligns with what we discussed in #9890 (comment) and I think it's ready for the fix to go in. |
fa2ca54
to
59437bf
Compare
Looks like there’s some issues with older versions of node and assert.fail 😓 |
This change makes rule-tester check messageId directly by value provided instead of the current behavior, which is to check the messageId's message value against the message returned from the rule at runtime.
59437bf
to
ff35ff8
Compare
Ok, all fixed up and ready for review. |
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.
LGTM, but would like to wait for other team members to review. Thanks for contributing!
Closing and reopening to make sure Travis/AppVeyor still pass with this change against latest master. Then I'll merge this in if all goes well. |
What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
This PR:
RuleTester
comparemessageId
in the test tomessageId
in the runtime error.tests/lib/rules/no-fallthrough.js
where the wrong message and type data was being passed through.What changes did you make? (Give an overview)
Currently, when
RuleTester
is used with amessageId
property in the error section, the underlying implementation looks up the raw message string fromrule.meta.messages[messageId]
and compares it with the runtime error string produced by the rule.All other properties checked in
RuleTester
's error section (message
,type
,line
,column
,endLine
,endColumn
) are direct comparisons to the resulting data, which makes the behavior ofmessageId
an unexpected and confusing developer experience.This PR addresses this by changing
messageId
checks inRuleTester
to be direct comparisons.Is there anything you'd like reviewers to focus on?
This partially addresses #9890, fixing the DX of
messageId
without dealing with the more contentious issue of surfacingdata
in the public API.