Editing the created role on the manage roles page in the legacy ui

Hey devs, am currently working on RATEST-274 where am creating an automated E2E test workflow for Roles and Privileges. The pull Request to the work being done to that effect is at RATEST-274: RefApp 2.x Roles And Privileges Workflow Test by mherman22 · Pull Request #270 · openmrs/openmrs-contrib-qaframework · GitHub .

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.

cc: @irenyak1 | @sharif | @kdaud | @jonathan | @mozzy

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).

3 Likes

Thanks for the insight. Will get back here with results

this does the magic, thanks once again @ibacher for the insight expecially on

since it clearly explains that By methods not necessarily have to be Static

1 Like

@mherman22 is this something we can sync tomorrow and look through it together.

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.

1 Like

Thank you so much for the insights, the learning curve is going up and i like that. I addition i will leave automated testing - What makes a good selenium locator? - Software Quality Assurance & Testing Stack Exchange here!

@kdaud is it high time we sorted the qa codebase and got rid of the xpath selectors? Because i see a couple of them there

@mherman22 do you mind logging a ticket and share a working PR to take a look?

cc: @sharif @irenyak1

1 Like

please assess it [RATEST-285] Getting rid of Xpath Selectors from qa codebase - OpenMRS Issues

please assess it [RATEST-285] Getting rid of Xpath Selectors from qa codebase - OpenMRS Issues

@mherman22 I skimmed through the ticket and felt worth to move it to → Ready For Work.

1 Like

@mherman22 , @kdaud Hope this covers the entire codebase (the bdd and legacy tests)

yes

because the pages are being shared by both BDD and legacy tests.

1 Like

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.