-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[TestModernization]: Add test modernization to TextField #4456
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
Conversation
size-limit report
|
kyledurand
left a comment
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.
Looks good but I'm suspicious about the find('div', {role: 'button'{) bit. If you have context on how that role is getting passed to a div please let me know
| .find('div', { | ||
| role: 'button', |
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 find this a bit jarring. Why would a div have a role of button on it? Looking at the TextField component it looks like the role doesn't get passed to the div with the onClick handler?
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 was not 100% of the mechanics of it getting passed down. This solution was from converting
element.find('[role="button"]').first().simulate('click');from the legacy suite and then debugging to find the specific element that the above (and similar) are targeting.
The debug output for these (console.log(element.find('[role="button"]').first().debug());) returns the div element with this role:
<div role="button" ...Looking at it closer, it looks like this is rendered by the Spinner component, which accepts a handleNumberChange callback, which itself accepts a number (1 for increment, -1 for decrement) and then calls the onChange which is being tested.
I believe the role is to indicate the div is being used a button.
One option would be to refactor these test selectors to directly call onChange on the <Spinner> rendered in the TestField, as reaching down into the sub-component feels like behaviour that is/should be tested within the Spinner itself.
e.g.
element.find(Spinner)!.trigger('onChange', 1);This proposed change would most likely require additional changes in Spinner.test.tsx tests, which currently tests the callback props are called, but does not test if they are called with any of the hardcoded values defined on the Spinner div buttons(1 or -1).
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.
Gotcha, thanks for looking into that @rdott ❤️ that makes sense. I just did a test with my screenreader and all is well.
!
WHY are these changes introduced?
I am updating existing tests for TextField components to use the new modern framework.
WHAT is this pull request doing?
Part of test modernization (https://docs.google.com/spreadsheets/d/1GBuEZbOpVYJLNISK7gL69DU8rCxocn5L5GYaKtPXPbU/edit#gid=1498187033), updating tests using {mountWithAppProvider} from 'test-utilities/legacy' to {mountWithApp} from 'test-utilities'.