-
Notifications
You must be signed in to change notification settings - Fork 404
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
toHaveStyles doesn't work with a CSS variable #649
Comments
Hi thany, I think the reproducer link isn't correct:
|
I think this is it: The share button in codesandbox doesn't work properly 😑 In the mean time, were you not able to reproduce the problem going off my description? |
That link works! Guess I'll create my own issue... |
Sorry, I guess I was making assumptions 😀 Anyway thanks for noticing my original mistake. |
@testing-library/jest-dom
version: 6.6.2node
version: 20.18.0vitest
version: 2.1.3npm
version: 10.9.0Relevant code or config:
Button
is an MUI Button, but it doesn't matter, as the repro will show.What you did:
The button background is declared in CSS with a variable.
What happened:
The unittest claims the background color as being
ButtonFace
rather than literally anything sensible.Reproduction:
https://codesandbox.io/p/sandbox/5z6x4r7n0p(edit: whoops)https://codesandbox.io/p/sandbox/react-testing-library-demo-forked-kkn5xt
Problem description:
The
toHaveStyles
assertion is not parsing CSS variables correctly, or at all. It seems to work with sort of a user agent default or something. CSS variables cause similar issues when used on (and testing for) other CSS properties.Suggested solution:
I don't know if this is related to years-old issues about toHaveStyle and css variables, so it's possible the problem is just returned from the dead and back with revenge (maybe a bit less dramatic), or this is a totally new issue.
The point is, a CSS var should be parsed and resolved, so a unittest can test for the value that would be visible. I'm not sure if this is a helpful suggestion though, because it seems quite obvious, but perhaps CSS vars were never a consideration in the first place.
The text was updated successfully, but these errors were encountered: