Testing ids (data-testid)

[ivank]

We're writing some end-to-end tests for react-admin (selenium) and its hard to select the exact items we want. Apparently we're not the only ones, some people have stack overflow discussions about it too (https://stackoverflow.com/questions/51897935/how-to-test-a-resource-controller-with-unit-test).

There are already some data-testid attributes throughout the code, but it seems its designed for your internal testing, rather than a feature to be used. Maybe you can standardise this and provide data-testids in some key places or allow the user to enter them themselves.

Just passing data-testid attributes in inputs works mostly, but not for dynamically generated items like app menu or Datagrid rows.

We can try and write a PR for that change ourselves, if you think sprinkling data-testid-s here and there is the right approach for something like this?

[djhi]

Hi, thanks for the offer. We don't think it's a good idea though. Although we do have some of those attributes currently, we plan to remove them and favor a user centric approach to those tests, using Cypress and @testing-library/cypress. This would avoid relying on implementation details which can change a lot between versions of Material-UI. Besides it helps ensuring the application is accessible (not bulletproof though).

[ivank]

How would you suggest going about writing end to end tests for react-admin then? Do we need to try targeting "text on page" kinda selectors with @testing-library/cypress? While that generally works, it makes testing a bit more brittle in my experience.

Some form of testing ids that allow you to target elements for testing explicitly allows very broad refactoring, since you've encoded your intent in the test, not the visual mapping to it.

I can understand that's certainly a trade-off on your part though - "brittleness of material ui" and "brittleness of user project" and all that. All that is unless you have a much better solution that I'm missing, would be awesome if that's the case.

[djhi]

Do we need to try targeting "text on page" kinda selectors with @testing-library/cypress? While that generally works, it makes testing a bit more brittle in my experience.

That's what we do on our projects yes. We experienced less brittle tests with this approach, especially using Cypress. Besides, and that's the most important part, tests are really close to what users would do with our app. In our experience, it requires less work on the tests when your refactor the application markup without changing what it actually does.