The challenge am facing however is when editing a role stored in the table on the manageRolesPage that the test creates each time it is triggered. This is because this particular page lacks a search field unlike the managePrivilegesPage(which has a search field).
The other dynamic with the manage Roles Page is that the roles are stored in alphabetical order.
Any insight on how i can locate the role i have created on the DOM without having to hardwire the cssSelector/xpath like i have done here would be helpful.
Remember that Selenium’s By gives you a number of ways to select elements on the screen and CSS or XPath are not necessarily the best or only ones to use.
In this case:
By.linkText("<name of role>")
Also, there’s no reason that the selectors must be constants. E.g., it’s just as reasonable to do something like:
public EditRolePage goToEditRolePage(String roleName) {
if (roleName == null || roleName.isEmpty()) {
throw new IllegalArgumentException("roleName must be provided");
}
clickOn(By.linkText(roleName));
}
(A similar XPath selector might be something like //a[text()='<role name>'], but that seems like a lot of unnecessary trouble).
I add a vote on @ibacher’s suggestion over using xPath when retrieving elements.
If you use an absolute xpath and the application under test evolves, the xpath query you use to identify the element will break, forcing you to identify back those elements.
If you write a relative Xpath by selecting the dom by using the wildcard, like:
//*[contains(@class,'roleName')]
This query will affect the performance, because you select the whole DOM to locate that specific element. On modern browsers, it not a big deal, but on mobile… You’ll slow down the execution.
We can rather use other locators(id, linkText, cssSelector, etc) that can hardly break.
Something to clarify here. i think we are leaving out @ibacher part of his comment. Can we consider both xpath and CSS selectors at once and have full suggestions before we finalize of getting rid of xpath . i think @ibacher’s suggestion was about how we use By that it gives alot of extensions to select an element.
My question is .Why are we getting rid of Xpath selectors from the entire code base since it have been working perfect.I think @ibacher meant that @mherman22 can use different approach as suggested above without entirely basing on xpath or css selector. cc @ibacher point of clarification.
i think the whole idea is to try as much as possible to limit the usage of xpath selectors in our codebase. As i was working through changing some xpaths to use either id, cssSelectors,className or linktext and partiallinktext, i realised some of the xpaths can’t be changed since in those chases they were the best option to use and still are.
My suggestion is let’s change those that are changeable. Exception should where XPath is okay to be used/maintained is if an element to be located has no ID,CLASSNAME or NAME. In the order of usage/preference, By.XPATH should be last.