React-testing-library: Better testing of input checkbox/radio

[julienw]

I found out that it's not possible to get the status of a checkbox using a simple assertion like expect(container.firstChild).toMatchSnapshot() because the checkbox's state isn't in the DOM. You can see the snapshots for both states here: https://github.com/julienw/testcase-react-testing-library/blob/testcase-1/src/__tests__/__snapshots__/hello.js.snap. Both snapshots have:

    <input
      name="checkbox"
      type="checkbox"
    />

You can run the tests for this project with these commands:

git clone https://github.com/julienw/testcase-react-testing-library
cd testcase-react-testing-library
git checkout testcase-1
yarn install
yarn test

The same problem happens for radio buttons.
I don't have a good idea at the moment, because I believe the DOM serialization is handled by Jest. Maybe with a custom serializer?

This is a problem I found while migrating our tests for enzyme. Because enzyme relies on the result of render instead of the DOM, we get the value properly as a result.

[kentcdodds]

Interesting. I'd be fine linking to a serializer, but I don't think I want to include one. The reason is that I'm not a huge fan of using snapshots for testing UI. I typically encourage more granular and specific assertions.

That said, if you build a serializer that supports this and it gets sufficient traction then maybe we could built it in. Actually, this may be a good thing for jest-dom to support (cc @gnapse).

In either case, I'm going to close this for now because it definitely wouldn't go in react-testing-library and probably doesn't belong in dom-testing-library either.

[gnapse]

Took note. Thanks for the referral. It does sound like something jest-dom could fit in better, because this project is not jest-specific (the main reason for which custom matchers were extracted into jest-dom in the first place).

[alexkrolick]

This isn't something that JSDOM will support either since the .value and value attribute are different things. It only works because React components have the value prop declaratively synced with the .value, so a string serialization doesn't know the difference.

https://codepen.io/alexkrolick/pen/NELEKE?editors=1011

This is a common source of bugs outside React.

[julienw]

I know the React folks will change their way of handling inputs in React 17, moving out of controlled inputs.