Test for Applied Styles breaks if styles are not inlined, as example shows about avoriaz

[eddyerburgh]

Hi thanks for the issue, I'll have a look and try for a fix tomorrow

[eddyerburgh]

So I've changed the style method to return the computedStyles instead of just inline styles. I add the element to the DOM when style is called and run getComputedStyle on the node.

It's not ideal. getComputedStyles returns the resolved style, so setting background: red results in a computed style of rgb(255, 0, 0) none repeat scroll 0% 0% / auto padding-box border-box. Not an ideal solution.

This also breaks style when using jsdom. I'm going to look into it tomorrow, but the problem is that stylesheets aren't being rendered in jsdom (document.styleSheets).

I think it's better though to have this working in a browser than to keep the inline only implementation.

Fix is available in 1.4.0 - https://github.com/eddyerburgh/avoriaz/releases/tag/1.4.0 . Which is live on npm

[eddyerburgh]

After sleeping on it, I've come up with a better solution.

I've deprecated style, since it is not reasonable to expect someone to assert style.color equals rgb(255, 0, 0) none repeat scroll 0% 0% / auto padding-box border-box when your css rule is color: red.

As a solution I've added the hasStyle method. This takes a style and a value as parameters and returns a boolean. It works on all computed styles (i.e. styles applied from stylesheets).

I've bumped to version 1.5.0 on npm and am about to update the example projects.

[JeffWeim]

Thank you @eddyerburgh for the quick fix. Very much appreciated.

This is a moot point now, but just FYI. I had tried the fix in the 1.4.0 release, and when I had the style in a <style></style> tag within the .vue file, I was getting expected some HEX value, but actual was rgb(0, 0, 0). When I debugged it appeared that after the insertBefore() method, the element in question only had it's initial CSS properties, black in this case since I was testing color.

Lastly, may I make a suggestion for the new hasStyle test. It looks like when window.getComputedStyle(mockNode)[style] executes, it's using rgb colors only. Could we add an option to convert this to HEX colors? I could make a PR if needed.

[eddyerburgh]

@JeffWeim that's expected behavior - and it's why I deprecated!

getComputedStyles returns the resolved values. Setting color: red results in a computed value of color: rgb(255, 0, 0)(in most browsers).

The resolved value of properties with multiple properties, like background: red, adds the default options. So the computed value is rgb(255, 0, 0) none repeat scroll 0% 0% / auto padding-box border-box!

I couldn't think of an easy way to convert the computed value into the value defined inside style tags.

hasStyle is my solution to this problem.

If your class is .color-black {color: black}, and you call .hasClass('color', 'black') on a wrapper of the element with class color-black, the test will pass. Even though under the hood it is comparing the computed value rgb(0,0,0) with rgb(0,0,0).

It can take a CSS color or hex value as input and apply these styles to a temporary node. it then compares the computed value of the temporary node with computed value of the node you are testing on. Under the hood it converts to RGB, but the outcome is still the same.

So I don't think there is any need to convert to hex.

If you do want to contribute though, I want to add support for direct sibling and sibling combinators in the find method 😄 .

[JeffWeim]

@eddyerburgh Thanks, that explanation makes more sense.

I can take a look and see if I can come up with something!