Idk why exactly but using IDs for styling has been discouraged for a while and now every application I’ve ever worked on had been styled using classes that are usually unique anyway
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 like how
garageis a class butcaris an intrinsic element.Maybe garage is just a class styling for a generic “room” After all, it’s got 4 walls and a few doors
Idk why exactly but using IDs for styling has been discouraged for a while and now every application I’ve ever worked on had been styled using classes that are usually unique anyway
Should I bother using just classes or can I keep making ids?
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).