When CSS and ID are unique go for it, however, when the above two approach does not help in resolving finding unique nodes, then do not be shy to use 'relative xpath'
- Use relative xpath w.r.t to a marker in the html section of interest
- Use wild card features of xpath, always w.r.t marker
- Use functionality that xpath engine provides e.g contains, text ..
- Keep the relative xpath short. hint: A relative xpath may contain
- a marker + a wild card
- a marker + relative path to wild card+ wild card
If relative xpath are used, and if relative xpath are readable, which it should, because we are finding location on html using xpath w.r.t a marker, then, the xpath engines in all browsers are good enough to resolve them, in the year 2016.
of course, there could be some performance issue but there is no way, the current xpath engines would fail in any browser
Relative xpath are as simple as or similar to, navigating folders relative to a current folder, on a command console or bash
Asking developers to provide additional ids or distinct css (just) for testing could appear simpler, but it will pollute the front-end code base with markers thats used only for QA. On a long term, its not the correct approach
Testability of app counts, however make sure, one has explored all the options
Circumstances when CSS and ID may not helpful:
@michael durrant: provides a nice and a very simple example of case: when css is better or equivalent to xpath and when it comes to question of 'readability'. Of course, 'absolute xpath' should not be considered as it gets long. I have been insisting only on 'relative' xpath throughout above