Hey @IgnusG, thanks for the report!

This method however relies on .getBoundingClientRect which is not available in jest - or rather it is but all the values are set to 0

This seems like a testing limitation. In Material UI's Rating tests, there's getBoundingClientRect stubbing: https://github.com/mui/material-ui/blob/master/packages/mui-material/src/Rating/Rating.test.js#L44. Do you think that's a good enough workaround for your use case?

Since the issue is missing key information and has been inactive for 7 days, it has been automatically closed. If you wish to see the issue reopened, please provide the missing information.

Hey @DiegoAndai 👋

Yeah I also resorted to stubbing to resolve this issue. Maybe MUI will handle this edge case more gracefully in the future but until then I think it's a good enough solution 👍

I would only suggest to add this gotcha to the Rating component's documentation. I couldn't find anything in there about this behavior and it took me a few hours of digging in the source code to find out this was the cause.

In the meantime, for anyone else intimidated by the stubbing workaround, another way to avoid this issue when testing the component is to set the skipHover option to the userEvent setup:

const user = userEvent.setup({ skipHover: true })
user.click(screen.getByLabelText('2 Stars'))

I would only suggest to add this gotcha to the Rating component's documentation. I couldn't find anything in there about this behavior and it took me a few hours of digging in the source code to find out this was the cause.

I agree that documenting this would be useful. I will add the ready to take and good first issue to see if we get any contributions. The work would be to add a small section in the Rating component docs about stubbing/skipping hover when testing.

If anyone is interested on working on it, let us know 😊

@DiegoAndai can you please assign it to me? I'd like to work on it.

@rajabhi21 sure! Go ahead. Let me know if you need any help. Thanks in advance.

Hi @DiegoAndai as i've not seen any progress on this for last two weeks. I decided to try my luck. Please find attached PR. I probably forgot about the label :( . #44129

This is how the component is tested:

So far we avoided @testing-library/user-event in the test as it's slower and hides events away, sometimes having wrong behavior too relative to the platform. In the reproduction, this works:

 // @vitest-environment jsdom

 import { Rating } from "@mui/material"
 import { render, fireEvent, screen } from "@testing-library/react"
 import userEvent from "@testing-library/user-event"

 import { describe, test } from 'vitest';

 describe('Rating', () => {
     test('Rating', async () => {
         const user = userEvent.setup();
         render(<Rating onChange={(_, newRating) => console.log('newRating', newRating)} />);
    
-        await user.click(screen.getByLabelText('2 Stars'));
+        fireEvent.click(screen.getByLabelText('2 Stars'));
     })
 })

https://codesandbox.io/p/devbox/wispy-fire-7lsnzs?file=%2Fsrc%2FApp.test.tsx%3A22%2C1

Now, yeah, I see @testing-library/user-event has been growing a bit in popularity: https://npm-stat.com/charts.html?package=%40testing-library%2Fuser-event&package=%40testing-library%2Fdom&from=2020-10-15&to=2024-10-15. Something from 43% to 59% in 4 years.

We have 1. docs as a lever, I think that we also have:

2. Add a test with user.click to make sure it works and be something others can copy
3. Consider special handling in the logic if getBoundingClientRect is not available, effectively for tests, we have a couple of those already in the codebase. Lately, we discussed this in [data grid] Tests fail with: "IntersectionObserver is not defined" after upgrading to x-data-grid v7.3.2 mui-x#12983 (comment)

On updating the docs 1., my instinct as a developer would be to go straight to check the source to see how it's tested, I wouldn't trust the docs so much because it doesn't run in the CI, it could get outdated. If we do 3. We don't need 1.

+1 on my end to do 3. then 2, and skip 1 because 3 might be a minimal overhead compared to the DX pain (not a strong preference, only #suggestion).

Can I ask whether are we gonna go with 3. -> 2.? I'd love to work on this approach

@NooBat, sorry for the delay. I agree with going with 3. and 2. If you (or anyone) wish to implement it, go ahead. Feel free to let me know if you need any help. Thanks in advance.