-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behavior of getNodeText
#867
Comments
Would be also useful for debugging large elements if we could have a print of the text only. Currently I'm relying on jquery: $('[data-testid="my-component"]').text() @jugglinmike Check if the Unfortunately it doesn't seem to be perfect either and it cannot be used for all elements: const button = document.createElement('button');
button.innerHTML = 'Hello, <span>world</span>!';
expect(computeAccessibleName(button)).toBe('Hello, world!'); Expected: "Hello, world!"
Received: "Hello, world !" |
I just stumbled upon this issue myself. I created the following sandbox to show case the issue. The test fail, because the text content returned is an empty string ( It looks like this is because we only look at nodes having a node type of |
The same issue is here: The code looks like:
The output:
|
@testing-library/dom
version: 7.28.1Relevant code or config:
What you did:
See above
What happened:
Problem description:
The docs for the
getNodeText
helper function state (emphasis added):That intention is in-line with the library's overall design goals, but it doesn't seem to match the current implementation.
Based on the description, I expected the function to return all text content of the node and its descendants (a la
innerText
). Given the following markup:A user would likely perceive the text "Hello, world!"
However, the current implementation only considers text nodes which are children of the input node. For the example markup, it returns "Hello, !"
Suggested solution:
As issues like gh-750 demonstrate, it's difficult to confidently say what a user will perceive when presented with text spread across many elements. It might be that this is too nuanced of a concept to expose as a general-purpose API, but I doubt it. For instance, we could observe screen reader semantics--that heuristic is probably imperfect, too, but its real-world usage makes the imperfection meaningful in a way that the current limitations of
getNodeText
is not.In any event, thanks for the excellent library!
The text was updated successfully, but these errors were encountered: