-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
test(developer) kmn compiler messages unit tests #11284
test(developer) kmn compiler messages unit tests #11284
Conversation
User Test ResultsTest specification and instructions User tests are not required |
…ler-messages-unit-tests
…ler-messages-unit-tests
As I am working on the kmcmplib C++ testing at present, the limited changes here should be reviewed and merged. The changes are essentially those to get tests impacted by an earlier fix (see #11136 and #11137) working again. I am not fully confident of the changes, as I am still growing in my understanding of the kmcmplib library - I will thus have to lean heavily on Marc's reviewing here. |
await testForMessage(this, ['invalid-keyboards', 'error_outs_too_long.kmn'], KmnCompilerMessages.ERROR_OutsTooLong); | ||
// callbacks.printMessages(); | ||
assert.equal(callbacks.messages[0].message, "Store cannot be inserted with outs() as it makes the extended string too long character offset: 5"); |
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 am not sure if we really want to test the message content because adjusting the text of a message should probably not be affecting unit 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.
Indeed, but I limited myself to just correcting the four failing tests. Six other pre-existing tests check the error message, only two do not, so for consistency I replaced commented out code to just print the message with assertions for the four tests I touched. Options include (i) simply removing the assertions on the messages on the four corrected tests, accepting the inconsistency; (ii) removing the assertions on messages from all existing tests as well as the four I corrected; (iii) looking to find a way (not sure how difficult this would be as I am not yet fully familiar with the interaction of the TS wrapper and kmcmplib) to read the messages from kmcmplib and assert these in the TS ... not really necessary in a unit test though ... operating more at the functional level; (iv) look to mock some aspect of the interaction so there is no dependency on the actual message text in kmcmplib.
Given effort vs. return, I am thinking (ii); what do you think?
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 (ii) makes sense, yes
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.
Done
…ler-messages-unit-tests
Changes in this pull request will be available for download in Keyman version 18.0.40-alpha |
Review and extend the unit test coverage of the kmn compiler messages.
Currently failing tests, see #11136 and #11137
@keymanapp-test-bot skip