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
Reference:
http://www.simple-talk.com/dotnet/.net-framework/xpath,-css,-dom-and-selenium-the-rosetta-stone/
More hints:
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
Additional info:
Relative xpath are as simple as or similar to, navigating folders relative to a current folder, on a command console or bash
Bad practice:
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:
When a javascript package, example extjs used, then the html generated in those cases, selecting unique elements based on CSS may result in multiple nodes from 10's to 100's. Also, IDs change based on extjs updates and based on browser (Strange case, but true)
@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