-
Notifications
You must be signed in to change notification settings - Fork 189
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
Tidy and add tests for resolveLanguages
commands
#937
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.
Nice! One minor suggestion that I thought of from reading the existing code and the Chai docs. There are of course many equivalent ways of writing the same test, so pick whatever you think is clear and readable.
expect(languages['cpp']).not.to.be.undefined; | ||
expect(languages['csharp']).not.to.be.undefined; | ||
expect(languages['java']).not.to.be.undefined; | ||
expect(languages['javascript']).not.to.be.undefined; | ||
expect(languages['python']).not.to.be.undefined; |
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.
Reading the Chai docs, I think there's an equivalent way of writing what we had before, with the added advantage of giving a more helpful message if the key is missing. Does this work?
for (const expectedLanguage of ['cpp', 'csharp', 'go', 'java', 'javascript', 'python']) {
expect(languages).to.have.property(expectedLanguage).that.is.not.undefined;
}
I also added Go since we can expect that to exist, might as well test all supported languages.
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.
Thank you, that looks nicer! (and also works 😄)
I'll merge this and start looking at more interesting tests in a follow-up PR.
1b1ea33
to
46abd02
Compare
First stage of tidying up and adding tests. See #915 (review) and the linked (internal) issue.
findLanguage
out of "run-remote-query" and into a more general place ("helpers"), since it's used in a few functions and this seemed like a more logical placeresolveLanguages
(basically copied from theresolveQlpacks
test above 😅)I haven't yet added a test for the other functions from #915, since they require a bit more setup. Stay tuned for a follow-up PR 😎
Checklist
N/A: no user-facing changes
@github/docs-content-codeql
has been cc'd in all issues for UI or other user-facing changes made by this pull request.