Open jamessan85 opened 1 year ago
@jamessan85 Think this should be transferred into a discussion?
I personally think that using a custom data variable within an element is just as clean as an identifier. Libraries such as cheerio can then be used to enable a whole range of tests for elements etc..
A good example of data in cheerio could be as straight forward as:
const $ = cheerio.load(result.text)
- (result.text being a snippet of html)
$('[data-custom=sr-text]').text()
- which will find the element with the data attribute and specific text which in this case is sr-text.
This makes the tests more readable as you know specifically that you're getting an element with a custom value with the data-custom then with the sr-text the specific custom element. This approach is also nifty when you have dynamic ids on elements or a list of the same element.
As far as I'm aware, approaches like this aren't used within the BSA.
What
Oftentimes we see users run into problems targeting their elements because:
Your application may use dynamic classes or ID's that change Your selectors break from development changes to CSS styles or JS behavior Luckily, it is possible to avoid both of these problems.
Don't target elements based on CSS attributes such as: id, class, tag Don't target elements that may change their textContent Add data-* attributes to make it easier to target elements