Developers often make mistakes by adding identical IDs or special data-* attributes to different UI objects. Instead of waiting for them to fix the problem, let’s make the selectors unique.
Developers often make mistakes by adding identical IDs or special data-* attributes to different UI objects. Most tools assume that IDs and special attributes are unique and create a selector according to this. This means that the first element of the CSS selector is the ID or the special attribute. For example, Gmail search in emails:
has an id: gs_lc50
and the short CSS selector generated by Google Inspector is:
#gs_lc50 > input:nth-child(1)
This is reasonable as the shortest the selector the more stable it is. Let’s consider a long selector starting from the body, i.e. the very beginning:
body > div:nth-child(25) > div.nH > div > div.nH.aqk.aql.bkL > div.aqn.aIH.nH.oy8Mbf.apV > div.aBO > div.aic > div > div
If any part of it changes, the selector becomes wrong. Especially child part changes frequently, for example from nth-child(25) to nth-child(26)
However, as mentioned, IDs for different UI elements may be the same. Here is an example, where the selector of tabs for ‘Requirements’ and ‘Test design’ below are the same generated by both Google Inspector and Harmony:
i.e. both are #tabs-\:rf\:--tab-0 > p
In this case, you can ask the developer to fix the selector problem, but it usually takes days as it’s the testers’ problem, not a user’s issue. A solution is to recognize the identical selectors and set alternatives that are different. In our example Harmony automatically generates different selectors, i.e., the Requirements tab has the selector:
[data-testid="feature-editor"] > div > div:nth-child(2) > div:nth-child(2) > [data-testid="split-view-view"]:nth-child(2) > div > div:nth-child(2) > [data-testid="split-view-view"] > div > div:nth-child(2) > div:nth-child(1) > button > p
while the Test design tab has the selector:
[data-testid="feature-editor"] > div > div:nth-child(2) > div:nth-child(2) > [data-testid="split-view-view"]:nth-child(1) > div > div:nth-child(2) > [data-testid="split-view-view"] > div > div:nth-child(2) > div:nth-child(3) > button:nth-child(1) > p
It’s not a permanent solution as the selectors are too long, but the test case works properly until the developer fixes the ID problem.
If you do not use Harmony, let's try to generate the duplicate selector with a different tool that may generate different selectors.
Note that test automation frameworks offer to force one of the UI elements in this case, however, for me, it’s error-prone and the least elegant.
Another problem with selectors is their names. The traditional coding solution requires assigning a meaningful name to each selector and using this name instead of the selector. In this way if the selector changes, you can modify it at a single place. However, this solution requires additional coding. Model-based testing requires much less work.
Harmony, for example, tries to give a meaningful name based on the ID, the special attribute, or the text belonging to the UI element. For example, the name of the selector is identical to the special attribute ‘add Coke’:
However, it can occur that no meaningful selector name can be added. In this case, you should modify the name to be meaningful. For example, in the ISTQB Glossary application, the attributes are only numbered:
You can immediately modify them so that when the selectors change, you can easily recognize them:
Now it’s easy to select the appropriate attribute.
Comments