4 ms·

Using xpath in a test on a dynamic and unpredictable DOM is a painful road to flaky, brittle tests. If you're writing tests for a system you have no control ove

• bryanrasmussen 3y ago
  >Using xpath in a test on a dynamic and unpredictable DOM is a painful road to flaky, brittle tests. sure, but more powerful and thus more able to handle situation than depending on css selectors. Also consider Robula+ https://tsigalko18.github.io/assets/pdf/2016-Leotta-JSEP.pdf https://tsigalko18.github.io/assets/pdf/2016-Leotta-JSEP.pdf https://tsigalko18.github.io/assets/pdf/2014-Leotta-ISSREW.pdf https://tsigalko18.github.io/assets/pdf/2014-Leotta-ISSREW.p...
  • onion2k 3y ago
    css selectors I wasn't recommending those either. roles or testids are much more robust than xpath and selectors. Robula+ I had a very brief glance over the paper and while it looks a lot better than plain xpath it still has some of the problems that I think make tests flaky. One of the suggested examples is "[contains(text(),'123456789')]" where '123456789' is an input field with that value. If the example text is changed the path will break. It's testing the content of the field, not what the field is* or what the field should do. An alternative would be a selector like 'getByRole('button', {name: 'Telephone'})' (getByRole comes from Jest, but more testing libraries have something like it) means you can change practically everything about the input field (xcept the aria-label or aria-labelledBy value and the test won't break. And, as a bonus, your app will end up more accessible.