Wrong style rule used

I’m trying to test some styles on my component and despite all tries I can’t get the test to pass.

After invetigating a little bit, I found that the way you are getting the component rules is what makes the test to fail.

Current behavior: Check this codesandbox: https://codesandbox.io/s/bold-glitter-h8rkb

When testing a styled component, the jest-emotion matcher validates against the wrong style rule.

Expected behavior: The jest-emotion matcher validates against the correct style rule.

More information: At the Checkbox test, I’m trying to validate that the hover state has the correct border, but as is, the matcher will validate the component style against the &:checked &:hover style rule, because it is the last style rule that has the :hover.

I debugged the matcher code locally and found the following:

Selectors for the component (and for the :hoverstate)

[
  '.css-ih6inj-StyledCheckbox:hover'
  '.css-ih6inj-StyledCheckbox:checked:hover',
]

Declarations

[
  {
    type: 'declaration', // This one is for the first selector `:hover`
    property: 'border-color',
    value: '#7E7E7E',
    position: Position { start: [Object], end: [Object], source: undefined }
  },
  {
    type: 'declaration', // This is for the second selector `:hover:checked`
    property: 'border-color',
    value: '#9E9E9E',
    position: Position { start: [Object], end: [Object], source: undefined }
  }
]

The declaration that was used to validate the component style

 {
  type: 'declaration',
  property: 'border-color',
  value: '#9E9E9E',
  position: Position { start: [Object], end: [Object], source: undefined }
 }

Which is the last declaration for the :hover state despite it is only applied when the component is :checked (and the component being unchecked on the test)

If I change the order of the style declaration on the component from:

&:hover ...

&:checked &:hover ...

to

&:checked &:hover ...

&:hover ...

the test passes but then if I test the style for the :hover when the input is :checkedit will fail because the matcher will compare against the last declared style for hover.

[nobreferreira]

I understand that a totally fine tuned matcher for every cases would be very complicated, but in this case we have a very limited matcher.

It would be nice to have at least a matcher that would recognize a rule with more than a pseudo-element and/or combinators targeting a specific element forgetting all the inheritance.

Anyway I think that this should be properly documented.

[jcleefw]

While I understand that this has been a problem for you and that it’s quite easy to get yourself into such a problem when using this matcher against pseudo-classes, I’m not sure if we can classify this as a bug.

The problem is that we don’t know in what state a particular element is - in the very same way we don’t know that it is in the :hover state so you have to tell us that it is. This target is not even limited to the root element - it would work for styles such as & span:hover - which makes this even more complicated.

To make this work for your case you could use such target: /^[^\:]+:hover/. This would disallow any other pseudos preceding the hover.

I agree that the target-matching algorithm could be probably improved, but I’m afraid I won’t have time to do it myself. PRs are always welcome!

This solution does work but the typing that toHaveStyleRule for target only receives RegExp. To allow that I’ve created a PR #2457