paypal/SeLion

Better support for pages with asynchronous requests.

ibugaienko opened this issue · 4 comments

Hi, we are running into some issues with page validation being executed prematurely, would you please consider the following scenario:
Given 3 pages,

  1. Login page (loginPage)
  2. Premium user home page (premiumHomePage)
  3. Standard user home page (homePage)

Suppose a user needs to provide their email/password and click a loginButton in loginPage, after which an asynchronous request is sent to a server which responds with a page to redirect to (premiumHomePage, homePage). While the browser is waiting for the response, some animation is shown to the user and the page remains the same (loginPage). If we were to use the following code:

loginPage.getLoginButton().clickAndExpectOneOf(loginPage, premiumHomePage, homePage)

Validation starts immediately after click() takes place, and since loginPage is among expected page objects (in case of server error for example) the above code will always return loginPage disregarding the actual landing page. The problem lies in the way that selenium handles asynchronous requests, as in the page is not loading so it will continue running the page validators.

For pages expressing this kind dynamic behavior it is desirable to forbid validation until the page finishes loading/updating. This would allow us work within clickAndExpect paradigm in cases like described above.

Solution Proposals:

  1. Add semantics for expressing negation in pageValidators list, e.g. new actions: isNotVisible, isNotPresent or !someElementLabel, !animationSpinner.isPresent;
    or
  2. Add another ListPropertyType to YamlPage format, e.g. loadingValidators and logic checking for these before the actual validation starts.

Please let me know what you think of this, and then I could work on it if approved.

mach6 commented

@ibugaienko Go for it! While it is not clear to me which approach makes the most sense -- though 1 seems less complicated -- I see the issue you are trying to address here and welcome a PR.

@mach6 Thank you for quick response. I have both solutions in my fork on separate branches. If you do not mind I could raise a PR for each so that you could choose which one looks most appropriate to you.
Also, please kindly note that this is the first time for me to make a contribution to an open source project so I would greatly appreciate to hear any feedback from you should you find anything requiring rework or improvement.

mach6 commented

@ibugaienko Not a problem. Yes, please raise a PR for each. We can review them both. In terms of contribution guidelines please review - https://github.com/paypal/SeLion#contributing if you have not already. In addition please make sure that the code does not contain any use of the TAB character (use four spaces instead) and has a righthand page margin of 120 characters.

mach6 commented

@ibugaienko closing this.. #357 and #358 are merged.