Use normalized string in getByText error if text not found

[Cerden]

Describe the feature you'd like:

When getByText fails to find text that has been normalized, the error message should show the normalized version of the string instead of the original.

Currently the error message shows the original un-normalized version. This can be confusing as often that exact text can be seen in the DOM logged out afterwards.

A downside is that it might not be immediately obvious why different text is being shown in the error from what was typed. IMO, if the user is unaware of the default normalization behaviour, this scenario makes it easier to track it down in the docs, and is slightly more representative of why the test is failing.

Describe alternatives you've considered:

Possible alternative is to generically mention normalisation in the error message (alongside text being split onto two lines)

Teachability, Documentation, Adoption, Migration Strategy:

N/A

[eps1lon]

Currently the error message shows the original un-normalized version

The error message shows the text you put in and the elements. The input isn't normalized. The text of the nodes is normalized.

Are you proposing to list the possible values for which the input would return a value?

[Cerden]

@eps1lon Ah I see - misunderstanding on my part. In that case I think the confusion is coming from the rendered DOM not showing the same text as the matcher use, which leads to scenarios where you can see that the text is the same, and directly log out a comparison that shows they're the same, but the matcher still fails.

I guess an ideal solution would be to have the rendered DOM normalised based on the same rules the matcher uses - would that be feasible?

[kentcdodds]

Hmmm... I don't know whether this is possible 😬 Anyone have ideas?

[eps1lon]

I'm not sure if this is a misunderstanding of the what the normalizer does or if we can do something. @Cerden Could you add a code example where you think the error message is misleading?

[Cerden]

@eps1lon
Example code:

App.js

import React from "react";

export const content = "Hello       React";

function App() {
  return <div>{content}</div>;
}

export default App;

App.test.js

import React from "react";
import { render } from "@testing-library/react";
import App, { content } from "./App";

describe("Tests", () => {
  it("should render the content", () => {
    const { getByText } = render(<App />);

    expect(getByText(content)).toBeInTheDocument();
  });
});

Error message:

The part that's misleading to me is that the text that the error message can't find and the text that's shown in the rendered DOM are the same. Ideally (IMO) it should be clearer that the text in the node has been normalised and so the matcher isn't matching against the same string that was originally passed in.

[eps1lon]

@Cerden Thanks.

Do you think it's enough the expand the error message to

Unable to find an element with the text: "Hello React" (normalized from "Hello    React")

?

[JoshuaKGoldberg]

Just piping in a couple months later: I have this issue & request as well, and that suggestion looks great to me @eps1lon. 😄

[MatanBobi]

🎉 This fix is included in version 8.12.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀