In E2E tests you should ideally be finding elements using labels or ARIA roles. The point of an E2E test is to use the app in the same way a user would, and users don’t look for elements by class name or ID, and definitely not by data-testid.
The more your test deviates from how real users use the system, the more likely it is that the test will break even though the actual user experience is fine, or vice versa.
This is encouraged by Testing Library and related libraries like React Testing Library. Those are for unit and integration tests though, not E2E tests. I’m not as familiar with the popular E2E testing frameworks these days (we use an internally developed one at work).
Tbh, I think for unique elements that’s a valid approach. It also enables easier element selection in automated e2e testing
In E2E tests you should ideally be finding elements using labels or ARIA roles. The point of an E2E test is to use the app in the same way a user would, and users don’t look for elements by class name or ID, and definitely not by data-testid.
The more your test deviates from how real users use the system, the more likely it is that the test will break even though the actual user experience is fine, or vice versa.
This is encouraged by Testing Library and related libraries like React Testing Library. Those are for unit and integration tests though, not E2E tests. I’m not as familiar with the popular E2E testing frameworks these days (we use an internally developed one at work).
I agree, but our tester is a bit lazy I suppose