4 ms·

I don't write tests based on xpath or ids - it is too fragile. I just stick a special class on elements I want to target, like class="test-save-user-button". Th

I don't write tests based on xpath or ids - it is too fragile. I just stick a special class on elements I want to target, like class="test-save-user-button". This allows changing the markup however you want without breaking tests. Just leave the test-* classes alone and you're fine.

geoelectric 4y ago
I was probably being a little too literal when I said xpath/id. Something unique like a custom class would be ideal, agreed. I just see that as a different kind of id that I find through an xpath query, which is what I really meant. To your point, though, the advantage of the class is that other things in your stack probably don't have opinions about what class you tack on, whereas they might want to define your (actual) id for you. IIRC this was how I asked devs to get around dynamic-UI runtime issues where the ids were also auto-generated.
EugeneOZ 4y ago
We add data-test-id, data-test-name, or data-test-value attributes (depending on the case) to our elements, and selectors are rock-solid.
- robgibbons 4y ago
  Using data-test-name or data-test="name" for e2e automation is the right answer. Data attributes are not going to conflict with your classes or IDs, won't get mangled, and they are tolerant to DOM, style, and backend/form refactoring. Essentially ignored by everything but your test framework.
  - epolanski 4y ago
    I disagree completely. E2E tests should mimic how users interact with the page and they see no data attributes. You can query by text, label, html semantics, position. Hell even for clickable icons you should have alt text.
    - EugeneOZ 4y ago
      Humans are faaar too smart to even try mimicking their behavior. All you can hope for is to make sure that the intended usage works fine.
    - robgibbons 4y ago
      Minor copy changes shouldn't break your tests. If you're selecting elements by their content the tests are much more brittle. Nor should unimportant stylistic changes in class, or changes in element order/positioning, break our functional tests. Thus we give important elements data-attributes which are resilient to all forms of refactoring.
      - epolanski 4y ago
        Let's agree to disagree I guess. HTML has specific semantics, and I find that interacting with applications the same way a blind person would (aria labels, text, etc) leads to much more solid tests. Copy changes are far from common on stuff like labels and any actionable item you aren't changing "submit" to "send" every other week or "pay" to "checkout" (moreover, such a button would have a meaningful aria role like "search" or "register"). And if you do, fixing the tests is generally very cheap and quick, so I see it as a non-issue. Nothing will change my idea that abusing data attributes (which are sometimes, but rarely, a necessary evil) leads to the great amount of non accessible and semantically incorrect bloated HTML we see everywhere on the net. Good tests will lead to better websites, and data-attributes do nothing to help in that direction.

geoelectric 4y ago

I was probably being a little too literal when I said xpath/id. Something unique like a custom class would be ideal, agreed. I just see that as a different kind of id that I find through an xpath query, which is what I really meant. To your point, though, the advantage of the class is that other things in your stack probably don't have opinions about what class you tack on, whereas they might want to define your (actual) id for you. IIRC this was how I asked devs to get around dynamic-UI runtime issues where the ids were also auto-generated.

EugeneOZ 4y ago

We add data-test-id, data-test-name, or data-test-value attributes (depending on the case) to our elements, and selectors are rock-solid.

robgibbons 4y ago
Using data-test-name or data-test="name" for e2e automation is the right answer. Data attributes are not going to conflict with your classes or IDs, won't get mangled, and they are tolerant to DOM, style, and backend/form refactoring. Essentially ignored by everything but your test framework.
- epolanski 4y ago
  I disagree completely. E2E tests should mimic how users interact with the page and they see no data attributes. You can query by text, label, html semantics, position. Hell even for clickable icons you should have alt text.
  - EugeneOZ 4y ago
    Humans are faaar too smart to even try mimicking their behavior. All you can hope for is to make sure that the intended usage works fine.
  - robgibbons 4y ago
    Minor copy changes shouldn't break your tests. If you're selecting elements by their content the tests are much more brittle. Nor should unimportant stylistic changes in class, or changes in element order/positioning, break our functional tests. Thus we give important elements data-attributes which are resilient to all forms of refactoring.
    - epolanski 4y ago
      Let's agree to disagree I guess. HTML has specific semantics, and I find that interacting with applications the same way a blind person would (aria labels, text, etc) leads to much more solid tests. Copy changes are far from common on stuff like labels and any actionable item you aren't changing "submit" to "send" every other week or "pay" to "checkout" (moreover, such a button would have a meaningful aria role like "search" or "register"). And if you do, fixing the tests is generally very cheap and quick, so I see it as a non-issue. Nothing will change my idea that abusing data attributes (which are sometimes, but rarely, a necessary evil) leads to the great amount of non accessible and semantically incorrect bloated HTML we see everywhere on the net. Good tests will lead to better websites, and data-attributes do nothing to help in that direction.