Dom-testing-library: getByText ignoring text in html tags

[ksoldau]

• DOM Testing Library version: "@testing-library/jest-dom": "^4.2.3",
• node version: v8.11.3
• npm (or yarn) version: 1.19.1 (yarn)

Relevant code or config:

// Error
describe('Range', () => {
  it('renders completely', () => {
    const { getByText } = render(
      <div>
        2<span>-</span>3
      </div>
    )

    expect(getByText('2-3')).toBeInTheDocument()
  })
})

// Pass
describe('Range', () => {
  it('renders completely', () => {
    const { getByText } = render(
      <div>
        2<span>-</span>3
      </div>
    )

    expect(getByText('23')).toBeInTheDocument()
  })
})

What you did:

In this specific example I am trying to assert that a range is visibile in the document 2-3. However, it's ignoring the - that is within the innermost span.

What happened:

I get this error: Unable to find an element with the text: 2-3. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.

I have tried to use a custom matcher, but I find that it still can't find 2-3 in the document.

// Error
describe('Range', () => {
  it('renders completely', () => {
    const { getByText } = render(
      <div>
        2<span>-</span>3
      </div>
    )

    expect(
      getByText((content) => {
        return (
          content.startsWith('2') &&
          content.includes('-') &&
          content.endsWith('3')
        )
      })
    )
  })
})

Reproduction:

https://codesandbox.io/s/react-testing-library-demo-l8to8

Problem description:

Unable to match any text within spans, strongs, bs, as, etc.

Suggested solution:

This is where the text content within the tags gets filtered out: https://github.com/testing-library/dom-testing-library/blob/792c5b7a0037499784c8d95a4a78c4079f928acd/src/get-node-text.js#L11. Since the textNode isn't a type 3, it gets ignored. I would suggest the ability to get the textContent from within a text node if it's a type 1. https://developer.mozilla.org/en-US/docs/Web/API/Node/nodeType#Node_type_constants.

Thought: I think I'd expect the getByText query to function similarly to innerText

[kentcdodds]

Thought: I think I'd expect the getByText query to function similarly to innerText

Unfortunately that doesn't work well because then pretty document.body would match pretty much every query 😬

I would suggest the ability to get the textContent from within a text node if it's a type 1

I think that's interesting. Could you make a pull request for that and we can explore it further?

[ksoldau]

I tried making the change and realised that my idea falls apart when a regex is used with getByText.

With the current implementation, each text node can only be matched once. But in the way I was thinking about doing it, multiple matches could be found over one test node. For example, if you had <div>2<span>-</span>3</div> and tried testing getByText(/-/), multiple matches would be found because the - is in 2<span>-</span>3 and -.

However, I do think that my problem isn't unique, and that this is something other people might want to test. Is there a suggested way of testing this that could be added to the docs? (Should I make a separate issue for this?)

Another common example that people might want to test:

// This would also error
it('renders completely', () => {
  const { getByText } = render(
    <div>
      Click <a href="somelink.com">here</a> for more information.
    </div>
  )

  expect(getByText('Click here for more information')).toBeInTheDocument()
})

Sandbox for above example: https://codesandbox.io/s/react-testing-library-demo-9eucp

[kentcdodds]

Yeah, this is definitely an issue. This is a good situation to use a data-testid I think 😬

[ksoldau]

👍 Will do. Should I close this issue or is that something to leave to you?

[kentcdodds]

Yeah, I don't think there's anything more that's actionable here. Thanks!

[didaquis]

Hi @ksoldau! Look tip number 4 of this post: https://www.polvara.me/posts/five-things-you-didnt-know-about-testing-library/

😉