react-testing-library why use test id

Question

I am using react-testing-library. In the document it says

Note that using this as an escape hatch to query by class or id is a bad practice because users can't see or identify these attributes. Use a testid if you have to.

I was wondering why this is a bad practice. I do not want to litter my code with data-testid. I already have ids and classNames in my component. Why is it not recommended to use them?

Thanks.

Oldenburg

Please, update the question with the link to the document. The quote lacks the context. – Gentlemanfarmer

Link to current version of docs, paragraph which mentions the "escape hatch": testing-library.com/docs/react-testing-library/… – Salientian

Answer 1

Good question. On the surface it wouldn't seem to make much sense as users can't see or identify testids either.

I'd say it comes down to minimising the fallout. If your test code queries by class or id, other devs are more likely to copypasta that than they are the testid usage, simply because you have to add testids to the components, which as you've seen, doesn't feel right. Using a testid says "I have no good options here, I'm forced to do this".

Sushi

Answer 2

react-testing-library is primarily intended for black-box functional testing. The use of selectors that are specific to the implementation can mean that a test tests the implementation rather than behaviour that could be observed by a user. While the use of data-testid designates that it is unambiguous and was added deliberately to make testing easier, while selectors can be ambiguous and be accidentally changed when the implementation is changed.

This doesn't mean that regular selectors shouldn't be used if they already serve the purpose, as long as a developer doesn't use them to test implementation in functional tests.

This also doesn't mean that react-testing-library cannot be used to test the implementation in isolated unit tests. It actually can but it lacks necessary features for that so this results in a lot of boilerplate code in comparison to Enzyme that was designed for that.

Gentlemanfarmer

Answer 3

I'm going to write something contentious - I think that this disclaimer in react-testing-library is wrong and opinionated.

I understand the "black-box" argument, but using data-testid has many benefits which ensure your code is testable, maintainable and supports SOLID:

• Precise & reliable - using getByText or one of the alternatives is prone to changes when the text changes and is unreliable in case there are other elements with the same text in the rendered DOM.
• Unchanging - Regardless of the implementation, you always use the same hook specific for testing.
• Unique on all testing levels - You can be writing unit, integration, e2e or qa tests, the test ids are always the contract for the tests you write, uncouples from implementation and translations.
• SOLID - you keep the separation of concerns by having a specific attribute for testing, which wouldn't change.

This article explains in more depth those principals: https://bugbug.io/blog/software-testing/data-testid-attributes/

Depress