toHaveStyle inconsistency with colors

[gnapse]

• jest-dom version: 1.11.0
• node version: 8.11.3
• react-testing-library version: 4.1.4

Relevant code or config:

const { getByText } = render(
  <span style={{ backgroundColor: '#123456' }}>Hello World</span>
);
expect(getByText('Hello World')).toHaveStyle('background-color: #123456');
// The above assertion failed

What you did:

I rendered an element with a specific hex background color in its styles.

What happened:

I can't assert back that the background-color style is indeed there. This is because the actual styles I get back from the element give me the color in the rgb(r, g, b) format:

    expect(element).toHaveStyle()

    - Expected

    - background-color: #123456;
    + background-color: rgb(18, 52, 86);

Problem description:

The problem is that users are forced to use the rgb() format.

Suggested solution:

It'd be nice if toHaveStyle would convert hex colors to the rgb(r, g, b) format so this is transparent for users. Otherwise document the caveat and maybe provide the user with some alternative or direct them to a library they can use to make this conversion, and that they make sure they always use rgb(r, g, b) either directly or by converting their hex value dynamically themselves.

[davidcai]

toHaveStyle treats color values differently. For example:

toHaveStyle(`
  background-color: #fff;
`)

...will fail, because #fff will be converted to a RGB value. However:

toHaveStyle(`
  border: 1px solid #fff;
`)

... is fine, because #fff stays #fff.

Yes, it is annoying. Would love to have consistent format.

[gnapse]

Does your work in #57 improve any of this?

BTW, sorry, I've seen all the work you've been contributing, but have had a hard time to be able to review every thing.

I do think #57 is ready. So feel free to merge it if you consider it done and good.

[smacpherson64]

Kk, I do believe it is ready! I am going to add the test case (border) above just to verify then will merge it in!

[smacpherson64]

@gnapse The PR has been merged as a fix:.

[gnapse]

🎉 This issue has been resolved in version 1.12.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[yuritoledo]

This still happens in:

  @testing-library/jest-dom": ^4.1.0
  @testing-library/react: ^9.1.3

@gnapse

[gnapse]

Can you expand a bit on the full example? In the screenshot we don't see the code being tested, how it sets this color that it is then not found.

Or better yet, a minimal reproducible example/repo.

[rrebase]

Here's a minimal example, where hex is still converted to rgb: https://codesandbox.io/s/heuristic-ritchie-5hgn8

[gnapse]

Hmmm, this is weird because that codesandbox tests work for me out of the box:

(I only needed to adjust the text in the query because it did not match the text inside the h1 but after I did that, it passed.)

I wonder why it passes for me and not for you.

[rrebase]

Oh it passes for me now as well, maybe it was just the text not matching 🤦‍♂️.

I realised that my actual issue was that I was trying to use toHaveStyle on an svg element. Even though the color attribute is shared with css it is not picked up. toHaveAttribute seems to be the appropriate matcher in this case. Also prettyDOM showing expected values as rgb in error debug added to the confusion.

[felipe-b-oliveira]

@gnapse I run some tests with CodeSandbox and it gives me the same error when i use styled-components, but it works fine when i put inline style as you did.

https://codesandbox.io/s/rtl-tohavestyle-error-fq669f?file=/src/App.js

[jayalfredprufrock]

I'm hitting this too with a different css-in-js library that uses a similar class-name injection approach as styled-components. It's strange though, because some tests that involve colors still pass, while others fail because of the automatic conversion from color names to rgb colors. I'm hitting this after upgrading from 5 to 6. It's obviously a tricky edge case so I'll continue to investigate and post back if I have any more information to go off of.