Confused by the prefer-presence-queries rule when used with the toBeInTheDocument matcher

[hovsater]

While I generally agree with the rules enforced by prefer-presence-queries, I'm having a hard time understanding why the following is an error.

expect(screen.queryByText("some text")).toBeInTheDocument();

The rule clearly wants me to use screen.getByText here. Wouldn't that make the toBeInTheDocument matcher completely unnecessary? If screen.getByText error out, then the node was not found, there's no need for the toBeInTheDocument matcher at all. I might as well do (albeit making the assertion implicit rather than explicit).

screen.getByText("some text");

Personally, I use the queryBy versions for presence checks and the getBy versions for when I make assertions/actions on the node itself.

// Presence checks
expect(screen.queryByText("some text")).toBeInTheDocument();
expect(screen.queryByText("some text")).not.toBeInTheDocument();

// Assertions and actions
expect(screen.getByText("some text")).toHaveAttribute('disabled');
await user.click(screen.getByText("some text"));

Would love to hear the reasoning behind this. 🙂

[Belco90]

Hey @hovsater!

First of all, we should probably improve the docs around this query so it's clear to everyone.

You are right about using queryBy* + toBeInTheDocument is fine, and using this matcher with getBy* queries is redundant in terms of asserting that an element exists.

However, if the element is not found, you'll see a misleading error like "null isn't in the document" which is not really helpful. Using a getBy* query would throw an error like "Unable to find an element with..." and then printing the whole DOM rendered. This makes it easier to understand that the desired element does not exist, providing the actual output rendered for debugging purposes.

Additionally, it also tries to encourage you to use the same type of queries for presence or absence for consistency.

We could say that this part of the rule doesn't prevent an actual error, but enforces a good practice.

[jtheberge]

Really glad I found this question posted because I had the same concern. Basically, if the presence assertion fails, the expect assertion will never actually handle the error since the getByText is in itself an assertion. Should we omit the expect altogether if it's just asserting toBeInTheDocument?

[Belco90]

Should we omit the expect altogether if it's just asserting toBeInTheDocument?

That's a personal choice. We encourage to always use explicit asserts through prefer-explicit-assert

[jtheberge]

Thanks, but if it's encouraged should it be added in the default configs? For example, it's not enabled in https://github.com/testing-library/eslint-plugin-testing-library/blob/main/lib/configs/react.ts, is that because expect is not part of RTL?

[Belco90]

That's one of the reasons, but mainly because it's a really opinionated one. Probably will be added at some point to the shareable configs.