I suppose that you expect to see this:
<a class="btn btn-default btn-sm green create-account-btn"
But if your web page is JavaScript-heavy, this node could possibly be
<a class="create-account-btn btn btn-default btn-sm green "
or at another chance
<a class=" green create-account-btn btn btn-default btn-sm"
Please find that in the above 3 instances the order of CSS class names in @class attribute differs. But those are equivalent in terms of CSS. This variation is completely valid. It is up to how JavaScript in the page behaves occasionally.
If the node was generated by JavaScript as <a class=" green create-account-btn btn btn-default btn-sm" , then your XPath
will miss the <a> node on the page.
How to overcome this difficulty of probability? You shouldn’t use equal operator (=) like [@class='xxx xxx '] to test the @class attribute. You should rather use contains(@class, 'xxx') function.
I would rewrite the XPath as follows:
//a[contains(@class,'btn') and contains(@class, 'btn-default') and contains(@class,'btn-sm') and contains(@class, 'green') and contains('create-account-btn’)]
Or, with the same meaning, the following might be better readable:
//a[contains(@class,'btn')][contains(@class, 'btn-default')][contains(@class,'btn-sm')][contains(@class, 'green')][contains('create-account-btn’)]
In case that there are multiple <a> elements with similar @class in the page, you can write it for uniqueness:
//a[@href="/comptes/sources"]