6

I have successfully installed eslint-plugin-testing-library and used overrides so it only warns me on code in test files.

However, it complains Avoid direct Node access. Prefer using the methods from Testing Library. for the following code props.children:

I want to be able to insert children, or a default node.

return (
  <>
    { // Other elements here. }
    {'children' in props ? (
      props.children
    ) : (
      <MyComponent {...props} disabled={disabled} />
    )}
  </>
)

What is wrong with this code? Why is props considered node access? How should I change it to satisfy the warning? Just add // eslint-disable-next-line testing-library/no-node-access?

Edit:

This is in a test file. It is creating an element in the same way as the main code. I do not understand why referencing props.children would warrant a warning. I wonder what is the justification for the warning and how else to perform the desired outcome.

Matt
  • 4,261
  • 4
  • 39
  • 60
  • 1
    This code is in a test file? What's the context? – dangerismycat May 01 '21 at 02:05
  • This might be a case where you should just use `// eslint-disable-next-line testing-library/no-node-access`. Couple of questions though: why are you replicating the main code's functionality in your test? Is it a dependency? Wouldn't mocking it make more sense? – juliomalves May 03 '21 at 09:03
  • @juliomalves That is a good question. I was isolating a (slightly different) component for testing, but I think it would be better to export the component from the main code and import it in the test. Thanks for the comment. – Matt May 04 '21 at 21:19

1 Answers1

4

Author of eslint-plugin-testing-library here! I'm sorry about this specific behavior being reported. Indeed, props.children is a valid usage and shouldn't be reported. Could you report this as a new issue? We can take a look at improving this rule in the future. Thanks!

Mario Beltrán
  • 521
  • 3
  • 6
  • 1
    Thanks @mario. I have submitted a report. – Matt May 16 '21 at 21:15
  • I have the same problem but in a different scenario. I'm using an external component, that also uses Material UI, an Icon Button that has an svg and I want to see what icon class is rendered. I think using DOM methods as 'querySelector' is not a bad idea and should not be restricted by default – Paul Pacurar Mar 02 '22 at 16:14
  • 1
    Querying elements by CSS classes is against the main principles of Testing Library. If you need to check if a certain element has a particular CSS class, I'd recommend querying it with provided Testing Library queries, and then using [`toHaveClass`](https://github.com/testing-library/jest-dom#tohaveclass) matcher. – Mario Beltrán Mar 03 '22 at 11:10
  • @MarioBeltrán `expect(productTableTree.children.length).toBe(3)` So, getting the error for something like this is to disregard? Just making sure that there isn't som e other equivalent method to use. – CodeFinity May 03 '22 at 17:49
  • 2
    @CodeFinity that's actually the case the mentioned rule aims to prevent! You should query the children of your table tree, and then check there are 3 elements. Something like: `const tableChildren = within(productTableTree).getAllByRole('row'); expect(tableChildren).toHaveLength(3)` – Mario Beltrán May 03 '22 at 21:05
  • I figured. Tx. Actually, I am now better understanding the use case for Snapshots and `react-test-renderer`. If we create the Snapshot, we can just inspect for things like that visually and then forget about it unless/until the Snapshot fails. Meanwhile, we use the RTL to worry about UI interactions, clicks, etc. – CodeFinity May 03 '22 at 22:04