-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[code-infra] Charts changes for vitest
#16755
Conversation
Deploy preview: https://deploy-preview-16755--material-ui-x.netlify.app/ |
vitest
await user.pointer({ | ||
target: rectangles[0], | ||
}); |
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.
Is this change equivalent? It seems a bit different to me, but I don't know what we're trying to test
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.
From what I understand, the user
is more browser like in submitting events.
Previousy, we had to do:
- pointerEnter: trigger the item interaction
- pointerEnter: shows the tooltip (not sure it was still necessary)
- pointerMove: To provide a coordinate for the tooltip
After that only pointerEnter was necessary to update the tooltip content which is the part we are testing
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 get that. My point was that before we were doing pointerEnter(svg)
and pointerMove(svg, { clientX: 150, clientY: 60 })
after pointerEnter(rectangles[0])
which seem slightly different than user.pointer({ target: rectangles[0] })
.
I wonder if we were testing pointer capture here and I was afraid we might be changing the test case we were testing.
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 wonder if we were testing pointer capture here
From what I remember, those are just here to open the tooltip.
The order of the events are probably more influenced by where my cursor was when I figured out why modification prevent tooltip to open than educated decision 🙈
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, what we are doing to open the tooltip is not the actual test, though it matters in the end.
user.pointer({ target: rectangles[0] })
does all the events we had to manually do before, so it is simpler
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, except the question from bernardo that I do not understand too
Thanks for taking care of that
@@ -29,14 +29,26 @@ const config = { | |||
describe('BarChart - click event', () => { | |||
const { render } = createRenderer(); | |||
|
|||
// TODO: Remove beforeEach/afterEach after vitest becomes our main runner |
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.
If you plan to move package by package, you could use a more search friendly message like TODO vitest:
to make them easier to find at the end of the migration
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'll find them regardless ;)
await user.pointer({ | ||
target: rectangles[0], | ||
}); |
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.
From what I understand, the user
is more browser like in submitting events.
Previousy, we had to do:
- pointerEnter: trigger the item interaction
- pointerEnter: shows the tooltip (not sure it was still necessary)
- pointerMove: To provide a coordinate for the tooltip
After that only pointerEnter was necessary to update the tooltip content which is the part we are testing
These are improvements made during the
vitest
PRI'm moving the changes out so that PR is leaner.
There are no specially notable changes for charts, mostly using the
user
events api instead offireEvent