-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Components: Refactor Placeholder tests to @testing-library/react #43069
Conversation
Size Change: -6 B (0%) Total Size: 1.27 MB
ℹ️ View Unchanged
|
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 for splitting this into a separate PR, it's much easier to review 💛
// Test for empty label. | ||
const label = getLabel(); | ||
expect( label ).toBeInTheDocument(); | ||
expect( label ).toBeEmptyDOMElement(); |
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 just noticed that label
is marked as required in the readme, and judging from the visual design I think that is correct. Should we fix the TS type to be required, rather than test for the empty case? I don't think it should happen in proper usage anyway.
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.
Did a search to check how Placeholder
is used inside Gutenberg, and there are a few places it is used without a label. Ex:
gutenberg/packages/block-library/src/block/edit.js
Lines 105 to 107 in c3f19c4
<Placeholder> | |
<Spinner /> | |
</Placeholder> |
gutenberg/packages/block-library/src/cover/edit/index.js
Lines 359 to 362 in c3f19c4
<Placeholder | |
className="wp-block-cover__image--placeholder-image" | |
withIllustration={ true } | |
/> |
<Placeholder className="wp-block-navigation-placeholder"> |
Seems that it was me in #42990 that didn't doublecheck that the readme and types matched. I feel that it makes sense to mark it as required, but not sure since it are used multiple places without one.
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. I'm not familiar enough with this component to make a decision, so let's leave it be then 😅 We can revisit when necessary.
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.
Yep. Sound good to me. Changed the required to No
in this PR to avoid confusion.
const getLabel = () => { | ||
const placeholder = getPlaceholder(); | ||
return placeholder.querySelector( '.components-placeholder__label' ); | ||
}; |
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 don't love this... I feel like the label should have some kind of meaningful semantics and not be a stray piece of text 🤔 But that's more of a problem with the component itself, so we'll have to leave it be for the purpose of this PR!
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.
Should we add a comment about it, at least?
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.
👍
Updated the test to only use querySelector
when we check if the elements is empty/don't exists. Added a comment on the where we use querySelector
.
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.
Looking good, thank you! 🚀
I guess a trend we're seeing in these legacy tests is a high amount of CSS class name assertions (also #42981). RTL purity aside, a lot of them are murky in their purpose. Are they intended to test logic, for example with complicated style variants? Are they intended to test styles, however unreliable that is? Are they intended to be a contract to the consumer that certain elements will have certain classes?
It isn't necessarily something we have to tackle in these RTL refactors, but it's something we'll have to clean up as part of #43083 anyway. I just wanted to mention that as long-term context as we continue to work on these refactors 🙂
What?
We've recently started refactoring
enzyme
tests to@testing-library/react
.This PR refactors the
<Placeholder />
component tests fromenzyme
to@testing-library/react
.Why?
@testing-library/react
provides a better way to write tests for accessible components that is closer to the way the user experiences them.Refactoring the test will also make it posible to add typescript to them. Related PR #42990
How?
Replace
enzyme
tests with@testing-library/react
ones.Testing Instructions
Verify tests pass:
npm run test:unit packages/components/src/placeholder
Screenshots or screencast