Part of our suite and test setup is that (using Browser library, but I don’t think that’s relevant for my question) we open the login page of our (single page) application and log on. Actual logon is only required for the first test in the suite, because successful logon is recognized in following tests in the same suite. Because at this point in our application we sometimes experience a delay, we are currently required to set time-out to 30 seconds.
A challenge that we now have is that there are two situations in which we have to take action:
The logon page is visible, and the user has not logged on yet (we verify this by checking for the existence of an element on this page). In this case we need to continue with entering the credentials and pressing the submit button.
The logon already has taken place for a previous test and as a result the main page of our application is displayed. In this case we can simple stop with the setup and continue with the actual tests.
Currently we wait a maximum of 30 seconds to determine whether the credentials need to be entered. If we do not find the required element after 30 seconds we verify whether the main page of the application is displayed.
Is it possible to use a construction where we verify whether either of the two conditions is met and if so execute the appropriate action (either enter credentials or just continue).
Something like…
IF (input_email element is visible then enter credentials) or (main application element is visible)
My goal is to not wait for 30 seconds if the user already has been logged on.
One suggestion, in your login test for an element that is on the main page but not available if not logged in use Run Keyword And Return Status to determine if the element existed, also set the timeout low like 5 sec so the login doesn’t take too long. As an example Wait For Elements State has a timeout option you can specify to overwrite the default 30 sec for just this one time.
Another suggestion, use Test setup and teardown to run the login keyword as a setup before all the tests, then your tests don’t need to check if you are logged in. you can also do the logout as a teardown after all the tests are finished.
Thanks for your suggestion. This is kind of what we have right now.
Open Process Designer Page
[Arguments] ${page_url}=${URL}
${old value} Set Browser Timeout timeout=30s
New Page url=${page_url}
Wait Until Network Is Idle
Set Browser Timeout timeout=2s
${status} Run Keyword And Return Status Get Element xpath=//exp-root[@app-id="processdesigner"]
Set Browser Timeout timeout=${old value}
Log ${status}
IF ${status} == ${FALSE} Logon In
The issue is in the line where the timeout is being set to two seconds. I’ve tried settings with 5s, 10s but eventually removed the line (being 30s). I had to do this, because we ran into situations where (after expiration of the timeout) the processdesigner element (indication that main application page is displayed) was not found. However in these situations the logon already took place and the element not being available was caused by a delay in the application / environment.
I think that we might need to start using your other suggestion and do the logon in the suite setup and opening of the page in the test setup.
For your type of app, the logon in the suite setup would be my preferred way, to deal with the page timeout issue you could use Reload or Go To in a test teardown, then after ever test the page is reloaded (connecting to the server and refreshing the login credentials.
A couple of other comments (not criticism and what you have is not wrong) on your Open Process Designer Page keyword:
you can do this then if the default is changed elsewhere you can retain it:
${old value}= Set Browser Timeout timeout=2s
rather than opening New Page every time (i’m guessing this is run for every test?) you could use Get Page Ids and count the number of pages, only if less than 1 call New Page otherwise call Go To with the same url. If you have many tests you’ll end up with many browser pages (tabs) and eventually this might cause performance issues on your test machine (this might be related to your timeout of 2,5,10 sec being unreliable?)
if you used Wait For Elements State you wouldn’t have needed to muck around with Set Browser Timeout allowing you to condense the keyword to 4 lines
A lot of the time solving issues like this is a bit of trial and error till you figure out what the app wants you to do to stay logged in.
Thanks once more! We now have a solution but this indeed opens multiple pages. We have a ‘Todo’ to have another look at it. I will certainly have a look at your suggestions.
This works for me:
${elements} Get Element States xpath=//exp-root[@app-id=“processdesigner”] then bool(value & visible)
Run Keyword If ${elements} Click ${element-1}
… ELSE Click ${element-2}