-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Navigation
: add controlled unit test, use modern Testing Library features
#41668
Conversation
Size Change: 0 B Total Size: 1.24 MB ℹ️ View Unchanged
|
await user.click( screen.getByRole( 'button', { name: 'Item 2' } ) ); | ||
expect( | ||
screen.getByRole( 'button', { name: 'Item 2' } ).parentElement | ||
).toHaveClass( 'is-active' ); |
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.
Would it be worthwhile to accompany this with a check that Item 1 no longer has the is-active
class? I notice we do something similar up in the first test of the suite, essentially confirming that there's only one active item at a time.
If yes, there may be additional places to apply this to is-active
tests elsewhere in the test case as well.
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.
Along those lines, I wonder if we should instead be checking for aria-current
rather than the .is-active
CSS. It would also make it easier to assert that no other links/buttons have an aria-current
.
expect( screen.getByRole( 'link', { current: 'page' } ).toHaveTextContent( 'Item 2' );
...aaaand I was confused a bit why this doesn't work, and apparently our RTL is quite outdated! The current
filter landed in @testing-library/dom
v8.2.0.
lena@Sieglinde gutenberg % npm ls @testing-library/dom
gutenberg@13.4.0 /Users/lena/Documents/Work/Automattic/gutenberg
`-- @testing-library/react@11.2.2
`-- @testing-library/dom@7.29.0
And unfortunately for us, the DOM Testing Library version bump landed in RTL v13, which drops support for React 17! So uh... never mind I guess 🙃
Side note: I bet we'll be experiencing more of these "wait why isn't this working?" moments, since the RTL docs aren't versioned. Maybe wp-components should have versioned docs at some point, too!
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.
Opened #41710 to try updating RTL-related dependencies to the latest version supporting React 17.
@testing-library/react@12.1.5
seems to pull @testing-library/dom@8.13.0
, so maybe we're still able to add support for current
🤞
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.
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.
Wow that was painless, didn't realize it was backported! Thank you for the quick version bump. Code looks super slick now 😎
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.
Changes look good to me 👍 How do you want to move forward? Chad's point is valid, but we could also wait until we can use the aria-current
filter so we can address it better in one go. I don't mind either way.
7df5aed
to
88a8fb7
Compare
88a8fb7
to
ad82fac
Compare
@@ -266,14 +261,14 @@ describe( 'Navigation', () => { | |||
screen.getByRole( 'heading', { name: 'Home' } ) | |||
).toBeInTheDocument(); | |||
expect( | |||
screen.getByRole( 'button', { name: 'Item 1' } ).parentElement | |||
).toHaveClass( 'is-active' ); | |||
screen.getByRole( 'link', { current: 'page' } ) |
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.
Note: only "Item 1" and "Item 2" have role="link"
since, in the example, their menu items are passed an href
attribute.
The rest of the menu items are rendered as button
as expected
What?
In the context of #41612, this PR enhances the unit tests for the
Navigation
experimental componentWhy?
More tests can help in making sure that a refactor doesn't introduce breaking changes.
How?
@testing-library/user-event
instead offireEvent
toHaveTextContent
,toBeInTheDocument
,toHaveAttribute
...)Testing Instructions
Code for the
Navigation
unit tests looks good, unit tests pass