toHaveStyles always report hover style

[thany]

• @testing-library/jest-dom version: 6.4.2
• node version: 20.11.1
• vitest version: 1.4.0
• npm version: 10.5.0

Relevant code or config:

render(<Button kind="primary" />);
const button = screen.getByRole('button');
expect(button).toHaveStyles({ 'background-color': '#5FA00C' });

What you did:

The above code should render a button with background-color: #5FA00C and it absolutely does. In a real browser I can see that it has the correct colour.

What happened:

In the unittest, it errors out, telling me that its background colour is rgb(62, 136, 0) instead. This is incorrect. This colour happens to be the hover color. I am not simulating a hover anywhere. So why is it testing for that?

Reproduction:

Forked Codesandbox
Although it no longer shows the tests tab, so I have no clue if this actually reproduces the problem. It appears codesandbox made a whoopsie. Sorry, nothing I can do about it.

Problem description:

I seem to be facing the opposite of issue 59 where it ignores hover styles. It always tests for hover styles now, no matter what (seemingly).

Suggested solution:

Don't do a hover on element to test toHaveStyle for, or something. Just ignore the hover styles.

[Myky8]

I have the same problem!!

• "@testing-library/jest-dom": "6.4.2",
• "@testing-library/react": "14.2.2",
• "@testing-library/user-event": "14.5.2",

[oskar-wilczynski-ynd]

I have the same issue on "@testing-library/jest-dom": "^5.16.1", one solution I found is using a similar method from jest-styled-components called toHaveStyleRule -- works like a charm.

Unfortunately, I guess it works only for styled-components...

[Myky8]

I found that is caused by "getComputedStyle" of JSDOM.

jsdom/jsdom#3607

[mxgit1090]

I found that is caused by "getComputedStyle" of JSDOM.

jsdom/jsdom#3607

I have been waiting for the fix for nearly a half year ...

[sangquangnguyen]

I found that is caused by "getComputedStyle" of JSDOM.
jsdom/jsdom#3607

I have been waiting for the fix for nearly a half year ...

You could use patch-package first to patch the fix here, no need to wait for nwsapi and jest to release it

[thany]

You could use patch-package first to patch the fix here, no need to wait for nwsapi and jest to release it

For end-user projects paid for by a commercial customer, in my experience, this will create headaches and tech debt in the future - for yourself if the customer is lucky, but web development companies usually enjoy some amount staff turnover.

If a project maintainer is on top of things all the time, and it's a product of love and whatnot, this is okay advice, and perfectly fine to implement in any downstream project or package. So patch-package is a great solution if the jest-dom people would implement it on their end instead 🙏🏻