-
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
ToolsPanel
: refactor unit tests to TypeScript
#48275
Conversation
Size Change: +217 B (0%) Total Size: 1.33 MB
ℹ️ View Unchanged
|
Flaky tests detected in e131cba. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4232322647
|
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.
Pretty straightforward. Nice work 🚀
I've left some questions and comments, but nothing blocking really.
hasValue: jest.fn().mockImplementation( () => { | ||
return !! controlProps.attributes.value; |
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.
This self-referencing was quite awkward. Thanks for fixing those!
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.
Yeah — I appreciate that it's self contained, but it's a bit akward and prone to breakage (and in fact TS doesn't like it)
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'm in general not a fan of this "shared state" patten across tests, but we have more pressing priorities at the moment
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.
Yeah, not a huge deal and something we can easily address if needed.
expect( disabledResetAllItem ).toHaveAttribute( | ||
'aria-disabled', | ||
'true' | ||
); |
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.
Any reason to not use .toBeDisabled()
here?
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.
Unfortunately toBeDisabled
doesn't take the aria-disabled
attribute into account (see the docs and testing-library/jest-dom#144)
} ); | ||
expect( resetAllItem ).toBeInTheDocument(); | ||
expect( resetAllItem ).toHaveAttribute( 'aria-disabled', 'false' ); |
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.
Any reason to not use .not.toBeDisabled()
here?
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.
Same as #48275 (comment)
@@ -1126,9 +1160,13 @@ describe( 'ToolsPanel', () => { | |||
expect( announcement ).toHaveAttribute( 'aria-live', 'assertive' ); | |||
|
|||
const disabledResetAllItem = await screen.findByRole( 'menuitem', { | |||
disabled: true, |
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 curious why we preferred to have a separate assertion for this when we can just have it in the query?
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.
That's because apparently the byRole
selector doesn't accept the disabled
option (docs) — which means that effectively this test was not testing what it was supposed to!
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.
Oh, right! Great catch!
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.
You can thank TypeScript :D
Nice one, thanks for refactoring this @ciampo! |
What?
Part of #35744
Refactor the unit tests for the
ToolsPanel
component to TypeScript, and therefore marks the end of the component's rewrite to TypeScript.Why?
See #35744
How?
Most errors were solved by adding types, or by refactoring the code in order to better suite TSC's inference.
See each commit for more details on all the changes.
Testing Instructions
No runtime changes — the only file changes is the tests file.