You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a div that supports resizing and have this div monitored by a resize observer. From what I can tell, I have no means of testing this behavior.
Looking at playwright and webdriver, they have methods that move the cursor, hover and click the mouse down. I would like to see this functionality in vitest.
The handling for mouseMove is a bit complex because it has to account for the fact that the frame is scaled; all the measurements took inside of it need to be scaled accordingly to get the coordinates within the full page.
@cyyynthia
Thanks for this code, but how do I get it to run?
I have copied this code into a file called src/testHelpers/customCommands, I have included this import in my setup file (src/testHelpers/setupBrowsers.ts) the import like this:-
The code I've provided is a Vite plugin that you need to register as you'd register other Vite plugins such as the JSX plugin. You will then have access to those commands within Vitest.
I crafted a lib vitest-browser-commands to do that! Currently, it only exports the mouse API from Playwright. Pull requests are welcome if you want to export more underlying APIs like mouse/keyboard for WebdriverIO. Please check the README for vitest-browser-commands for usage.
Beware, as our test suites grew larger we started to face significant issues with this ad-hoc mouse control implementations and found it to be extremely flaky as more tests are written. Disabling file concurrency is a must if you don't want seemingly inexplicable behavior to happen :)
I didn't get the chance to hack around a new mouse driver that would do best effort pointer event emulation by manually dispatching events (like you have to do in order to test touch-based interactions), but that's definitely something that'd be worth exploring to improve reliability. I've moved to other projects so I likely won't dive into that myself for a while.
If your page relies on the dragover event being dispatched, you need at least two mouse moves to trigger it in all browsers. To reliably issue the second mouse move, repeat your mouse.move() or locator.hover() twice. The sequence of operations would be: hover the drag element, mouse down, hover the drop element, hover the drop element a second time, mouse up.
In particular, the steps option in mouse.move() makes it much more stable.
I must say I'm not sure. It seems to be capable of emulating basic pointer movement from one element to the other, but I've had situations with complex interactive components where I had to test very fine grained behavior and how elements react relative to each other that would most likely not be easily emulated by this mechanism. It also lacks the ability to go from point A to point B in steps to emulate a more human-like dragging behavior.
That being said, it seems like it could work for situations where these don't matter, and perhaps the lack of absolute movements can be seen as a feature the same way the API is designed to encourage use of accessibility-based selectors. But I think relative positionning around a given element would be quite valuable.
I think their API could be quite hard to understand, to be honest. We can always extend it with our own interface. I am open to any API proposal that is not just a direct one-to-one copy from playwright or wdio. We don't want to take too many round calls (for example, see the upcoming wheel API: #9188. It tries to minimize the number of calls between the browser and the server), and it should be easy to understand.
Activity
cyyynthia commentedon Jun 10, 2025
I've been able to overcome the lack of
page.mouseusing the following custom plugin:The handling for mouseMove is a bit complex because it has to account for the fact that the frame is scaled; all the measurements took inside of it need to be scaled accordingly to get the coordinates within the full page.
KamBha commentedon Jun 27, 2025
@cyyynthia
Thanks for this code, but how do I get it to run?
I have copied this code into a file called src/testHelpers/customCommands, I have included this import in my setup file (src/testHelpers/setupBrowsers.ts) the import like this:-
And my config is setup like this:-
But when I use the command object I do not see these methods.
The commands only includes readFile, removeFile, and writeFile.
cyyynthia commentedon Jun 27, 2025
The code I've provided is a Vite plugin that you need to register as you'd register other Vite plugins such as the JSX plugin. You will then have access to those commands within Vitest.
See the custom commands documentation for more details
ocavue commentedon Oct 25, 2025
I crafted a lib
vitest-browser-commandsto do that! Currently, it only exports the mouse API from Playwright. Pull requests are welcome if you want to export more underlying APIs like mouse/keyboard for WebdriverIO. Please check the README forvitest-browser-commandsfor usage.cyyynthia commentedon Oct 25, 2025
@ocavue pertty cool to have it as a package. 😄
Beware, as our test suites grew larger we started to face significant issues with this ad-hoc mouse control implementations and found it to be extremely flaky as more tests are written. Disabling file concurrency is a must if you don't want seemingly inexplicable behavior to happen :)
I didn't get the chance to hack around a new mouse driver that would do best effort pointer event emulation by manually dispatching events (like you have to do in order to test touch-based interactions), but that's definitely something that'd be worth exploring to improve reliability. I've moved to other projects so I likely won't dive into that myself for a while.
ocavue commentedon Oct 26, 2025
@cyyynthia I have to use the
mouseAPI to test drag-and-drop behavior anyway, as quoted by the Playwright's documentation:In particular, the
stepsoption inmouse.move()makes it much more stable.sheremet-va commentedon Dec 22, 2025
Would Pointer API be enough for this?
cyyynthia commentedon Dec 23, 2025
I must say I'm not sure. It seems to be capable of emulating basic pointer movement from one element to the other, but I've had situations with complex interactive components where I had to test very fine grained behavior and how elements react relative to each other that would most likely not be easily emulated by this mechanism. It also lacks the ability to go from point A to point B in steps to emulate a more human-like dragging behavior.
That being said, it seems like it could work for situations where these don't matter, and perhaps the lack of absolute movements can be seen as a feature the same way the API is designed to encourage use of accessibility-based selectors. But I think relative positionning around a given element would be quite valuable.
sheremet-va commentedon Dec 23, 2025
Wouldn't it work like this? (From the API):
I think their API could be quite hard to understand, to be honest. We can always extend it with our own interface. I am open to any API proposal that is not just a direct one-to-one copy from playwright or wdio. We don't want to take too many round calls (for example, see the upcoming wheel API: #9188. It tries to minimize the number of calls between the browser and the server), and it should be easy to understand.