Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
CustomSelectControl
: add additional unit tests #56575CustomSelectControl
: add additional unit tests #56575Changes from 8 commits
8be9700
ec0847f
5306bf8
de49c49
2b33a3b
37b3cff
2e1da1e
948a131
f95022a
8db564a
220e01f
cc7f225
33cdc33
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Noting that if we reorder the fixture above, the test will break. Could make sense to access
props.options[ 0 ].name
hereThere 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.
Edit: I was thinking about the specificity from your previous comment rather than the ordering. I think we can use what you suggested above instead. Since the purpose of the query is to get the button element, not necessarily the first in the list. So my original comment below can be disregarded.
What do you think of specifying the text instead?
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.
Then we could check for
toBeVisible
instead?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.
Either way sounds good to me. Leaving it to your judgment, as it's a minor detail.
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.
Do we also need focus tests / assertions? Making sure that as we navigate with keyboard, the focused item is the one that we expect it to be.
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.
We have a few. When testing changing the selection via keyboard:
gutenberg/packages/components/src/custom-select-control/test/index.js
Lines 232 to 241 in 948a131
And when checking that the
onFocus
handler is called:gutenberg/packages/components/src/custom-select-control/test/index.js
Lines 327 to 351 in 948a131
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 added a few more in: cc7f225
Let me know if you think there should be any others!
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.
Maybe it could be nice to see some tests or assertions for:
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 for the suggestions! A couple comments/questions in regards to them:
Not possible currently, but its in the experimental version 😄 so hopefully soon
Are you referring to adding styles and classnames to options? Would that just be to ensure that it isn't applied to all items but specific ones? Just wondering how to test it without it being solely about implementation details. 😕
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! I don't think it's going to be about testing implementation details - it's the opposite, we would be testing the API, and how we can apply specific styles to separate items.
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.
Thanks! I've added a couple tests for this in: 948a131
Hopefully, I've captured what you suggested, otherwise I'd be curious for your thoughts/feedback.
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.
Thanks!
As mentioned above, it might make sense to add additional assertions for testing the selected value in addition to the selected option text content. Also, what happens if we select an item with an empty value (similar to having an empty string as
value
for anoption
element in HTML)?I think you've covered the rest well enough already 👍
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.
Are you referring to adding commented-out assertions that will fail, as suggested earlier? Would that help clarify why those assertions aren't there in the first place?
I'm curious as I was leaning toward the other suggestion - the reason being I think it's likely other things will come up in the new component that we may not have anticipated testing for here. As we bolster the tests in the new component, we may have additional tests/assertions to bring back to this one.
Since there isn't a value DOM attribute (just the prop for controlling the component), do you mean adding an empty string to
options.name
? Or something else? An empty string is valid for that and also forvalue
in Ariakit.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.
As a second consideration, I'm happy with the existing tests. Let's move forward and ship what we have, and we can always add another case if needed.