Regex support for .toHaveClass()

[onlywei]

Describe the feature you'd like:

With CSS-in-JS and CSS modules, it's pretty common for CSS classes to contain randomly generated unique strings appended to the end. This makes .toHaveClass() extremely limited.

While there are workarounds involving string matching on the actual class string, these are not ideal because many projects prefer to leave this eslint rule turned on: https://github.com/testing-library/eslint-plugin-jest-dom/blob/main/docs/rules/prefer-to-have-class.md

If .toHaveClass() could accept RegExp in addition to strings, that would allow projects to continue using eslint: prefer-to-have-class while also using CSS Modules / CSS-in-JS.

Suggested implementation:

A backwards compatible implementation that simply adds support for RegExp matching for .toHaveClass().

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

expect(deleteButton).toHaveClass(/^text-sm/)
expect(deleteButton).not.toHaveClass(/^text-lg/)

[gnapse]

Makes sense. Are you up to contributing this improvement?

[Namnika]

I also faced the same thing now:

expect(audioBtn).toHaveClass(/audio-btn/i)

and get this:

expect(element).toHaveClass(expected)
At least one expected class must be provided.

[gnapse]

I'm giving it a try in #563. One particularly contentious aspect of it is that I had to tread lightly with an existing feature of .toHaveClass: the ability to match the full class exactly when passing toHaveClass('…', {exact: true}). In the end, I opted for disabling regexp support when enabling this option, since it does not make sense to make it work with regular expressions, which are inherently about checking the class names partially and not exactly.

[vacas]

Hello! I saw the PR is approved by one, but the branch seems to be out of date. Is this being prioritized still? Do you need any support here, by any chance? This would be great for a test I've been just trying to write now.

Thanks!

[gnapse]

Thanks for the reminder. Will try to get it merged and released today.

[github-actions]

🎉 This issue has been resolved in version 6.3.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[vacas]

Hello!

@gnapse, thanks for tackling this! I really appreciate it 😄

So, I just tried this out (i.e. expect(el).toHaveClass(/disabled/) with a list of classes label select has-value root search disabled) and I'm coming across the following error: At least one expected class must be provided., but if I do expect(el).toHaveClass('disabled'), the tests do pass... am I missing something here?

[vacas]

Also, I just tried expect(el).toHaveClass(/disabled/, 'root') on the same example as above, and I'm getting str.split is not a function, but if I do expect(el).toHaveClass('root', /disabled/), all the tests pass - could there a check on the first argument of toHaveClass that might prevent it to be a Regex?

[vacas]

@gnapse, just wanted to follow up on this. Let me know if there's anything I can do to help here, yes?