Ability to assert mixed-checked checkboxes

[gnapse]

Describe the feature you'd like:

See testing-library/eslint-plugin-jest-dom#43

Specifically, the difficulty to asserting that a checkbox-like element is not checked or unchecked, but in a middle third state usually known as "mixed".

Suggested implementation:

It could be a new matcher toBeCheckedMixed, but I'm leaning more towards keeping it under toBeChecked, which could receive an optional argument 'mixed' (specifically that string, and nothing more), and will pass if the checkbox is in this third state. Without argument it will behave as today. When passed another argument, its behavior is undefined (maybe throw an error? or maybe we should support passing to it 'true' and 'false' and fail or pass accordingly, and still fail with anything else passed to it?)

Describe alternatives you've considered:

Keep using toHaveAttribute('aria-checked', 'mixed') but in addition to cause the linting issue linked to above, it does not cover the other way in which a checkbox can be mixed-checked: checkboxElement.indeterminate = true (ref).

Teachability, Documentation, Adoption, Migration Strategy:

Add to the documentation the new feature. It does not / should not break existing functionality.

[rubenmoya]

Hi! I'd love to take on this one to compensate the fail with the toBeReadonly PR 😂

About the matchers I like the idea of having toBeChecked('mixed') instead of toBeCheckedMixed, but I'm not so sure with true and false as arguments, toBeChecked('true') would be the same as toBeChecked so probably would end up adding more work in the eslint-plugin-jest-dom package to alert the user, and so would happen with toBeChecked('false') and .not.toBeChecked, what do you think?

Also, after reading about the "mixed" state I've found out that:

The switch role does not support the value mixed for the aria-checked attribute; assigning a value of mixed to a switch instead sets the value to false.

So we should take that into account too.

[gnapse]

Thanks for your input. Yeah, it does not make much sense to add the argument for the other cases. Which makes me think if it makes sense to add it at all. Maybe we should add toBePartiallyChecked after all. What do you think?

About the mixed state not supported on a switch, yes, we should take that into account.

[rubenmoya]

Yeah, I like toBePartiallyChecked better, it's more concise and it won't complicate toBeChecked with extra arguments and checks, also it will appear in autocompletion with toBe... so probably easier to use than using arguments, I'm sold!

[gnapse]

Thanks for your input. Will you take a crack at it with a PR?

[rubenmoya]

Sure! I'll give it a try

[rubenmoya]

We can close this right?

[gnapse]

Yup