How to render styles for tests?

[lukemorales]

When using something like styled-components we're able to render a component for testing and then test if that component has some style based on the use-case we want to test. With stitches, the rendered component only has classNames attached, but no reference to what styles those classNames apply, so there's no way to test styles based on conditions.

Is there something we can do on a test renderer or on jest setup file to make those styles be applied to the components?

[peduarte]

Hey! What are you trying to test though? You shouldn't need to test that the styles are applied, that's Stitches' job.

This repo does some basic tests: https://github.com/pffigueiredo/test-ui/blob/master/src/Button.test.tsx

[jkytoela]

I'm having the same issues.

[lukemorales]

@jonathantneal did you see our replies here? Just getting your attention again on this subject as there's no reply or reactions from you on the answers 😅

[jonathantneal]

Hi, @lukemorales. One of us should be able to investigate this relatively soon. Now that I know jsdom is involved, I have to suspect the issue is a lack of compatibility on their end (where I use the term "compatibility" similar to describing compatibility with Internet Explorer). The last time we investigated a jest issue involving jsdom, I wound up committing fixes to the cssom package that powered the jsdom package that powered jest (and the cssom package is no longer actively maintained).

[mryechkin]

Just chiming in on this - this exact use case is needed for us as well (testing defaults in a design system library). Currently we're using the same approach as @lukemorales above with styled-components, and would need to have similar tests after converting to Stitches.

[rogerluiz]

Hey! What are you trying to test though? You shouldn't need to test that the styles are applied, that's Stitches' job.

This repo does some basic tests: https://github.com/pffigueiredo/test-ui/blob/master/src/Button.test.tsx

this is like a bot reply aways the same, if i want to test the style, that every library like styled-component do, the stitches library have to, what the purpose of not do that?

[gmlnchv]

Hi, @jonathantneal. Wondering if you or anyone else has had a chance to look into this. Having an issue where getCssText() is always an empty string. I've also tried plugging in a test from here and everything is ok except getCssText() is an empty string:

Any pointers appreciated!

[gmlnchv]

FWIW, testing CSS using @playwright/test and the .toHaveCSS() matcher that comes with it, solves the issue for me (obv being an actual browser environment, not jsdom).

test('has default styles', async ({ page }) => {
    await page.goto('http://localhost:6006/iframe.html?id=styles-box--default');
    const box = page.locator('.c-lesPJm');
    await expect(box).toHaveCSS('width', '64px');
    await expect(box).toHaveCSS('height', '64px');
    await expect(box).toHaveCSS('border-radius', '0px');
    await expect(box).toHaveCSS('background-color', 'rgb(18, 66, 109)');
  });

[mryechkin]

Hi folks. Has anyone had a chance to look into this further?

We'd like to start moving our component library to use Stitches (currently on styled-components), and being able to do the kinds of tests @lukemorales mentioned is crucial for us. In my preliminary testing I'm running into all of the above-mentioned issues.

Has anyone been able to find a suitable workaround with Jest?

[deanlot]

Hi all,

Any updates here?

same boat, I’d like to use ‘.toHaveStyle()’ in my unit tests.

[grug]

We're in the same boat, too. We'd like to test defaults and overrides within our design system but unfortunately can't do it at the moment because of the lack of toHaveStyle() functionality.

[jared-paperspace]

I had a library for this called jest-stitches but I'm not sure what changed yet that made it break. It doesn't look like it inserts styles to the DOM in the test environment or it does so differently. Working on this tonight if any stitches contributor has a carrot to dangle.

[grug]

Hey Jared - if there's anything I can do to help contribute towards this, please let me know. I'm not a Stitches contributor but depending on timezones, I'd be happy to jump on a call and pair program a solution to this with you :)

[jared-paperspace]

@grug That would be awesome if we can make it work. I'm in Eastern Standard Time right now. Quick update: they're using bucketed media queries to house styles, but I haven't been able to make them render during tests yet. Posted this to their discord:

Is there something special that has to happen during render with require('react-test-renderer').create(children).toJSON() to make the sheets populate? I'm rendering components, the grouped sheets are there, but they aren't getting populated with styles 🤔 getCssText() doesn't return anything either

If we can figure that out, the rest is fairly trivial.

[CaioGrossi]

Hey guys, I`m facing this same problem. Any updates?

[ricardoalfaia]

I was working hard here at the company trying to indicate stitches in our project, but the test issue is making us back away from the difficulty of validating the applied classes as with styled-components using jest-styled-componets. Sad but I'll have to keep styled-components. Everything I see of example today doesn't include unit tests for component stitches. We have this gap for adoption

[ricardoalfaia]

Seems like we're all stuck at this point

[ricardoalfaia]

it would be nice to have something like .toHaveStyleRule('prop', 'value') or .toHaveStyle(...)

[mryechkin]

Yeah, absence of comparable matchers like that for Stitches was basically a non-starter for us. Decided to stick with styled-components

[LexSwed]

I think toHaveStyle is not what you really want. I think there are few solutions already that simplify and make visual testing faster, to avoid visual regressions, that work much better than testing arbitrary style rules.
You can always check that the classes are applied correctly through expect(el).toHaveAttribute('class', expect.stringContaining('variant-variantName')) (see doc).
If it's too cumbersome, you can always create a custom matcher.

[grug]

It's been a hot minute since I've looked at this, but I seem to recall that the code provided by jest-dom doesn't work in conjunction with stitches

[igortullio]

This work for me

[nasimbeem]

this works for me

[GilAlvez]

This worked for me, but I believe it's limited.
In my case, for example, I have a button component that has many base styles and compoundVariants. The only variation I can test using this method is 'size'. Everything else are unreadable classes, thus untestable.

[rntvicente]

Hi all,

Any updates here?

same boat, I’d like to use ‘.toHaveStyle()’ in my unit tests.

[rahul-budhia]

Hey everyone,

How do you suggest we test a show / hide toggle functionality?
What I use from jest is toBeVisible() and .not.toBeVisible(), which looks for css prop values like display and visibility. Since it doesn't work with stitches how do you work around it?

It currently feels like jest's .not.toBeVisible() check will not work in any case.

[hyjoong]

I'm having the same issues.
I would like to use '.toHaveStyle()' in the unit test, but I have encountered the following issues:

using toHaveStyle()

Button Component

const Button = ({ isDisabled = false, children, ...props }: ButtonProps) => {
  return (
    <ButtonStyled isDisabled={isDisabled} {...props}>
      {children}
    </ButtonStyled>
  );
};

// button style 
...
        border: "1px solid #00C896",

test code

it("~~", () => {
    render(<Quiz />);
    const checkButton = screen.getByRole("button", { name: /정답 확인/i });
    expect(checkButton).toHaveStyle(`border: 1px solid #00C896`);
  });

I set it to 1px, but I don't know why 2px is coming out.

https://github.com/hyjoong/quiz-app/blob/master/__tests__/quiz.test.jsx

[jpalvarez]

In the year 2023, cars drive themselves, and AI rules the world, but we can't do something simple like test a component using "toBeVisible" because stitches don't work (and apparently will never work) with jsdom. Awesome!

[mryechkin]

I wouldn't hold my breath:

#1149 (comment)