Hello,
I need your advice about an issue for my RobotFramework test.
When I try to run my test (verify the displayed data), RF doesn’t find the data because this data are loaded once the page is fully displayed (As i know, it’s the Angular behavior).
Here is an example :
Element Should Contain //h1/span[@class=“type_bien”] Appartement T3
The RF response is “Element ‘//h1/span[@class=“type_bien”]’ should have contained text ‘Appartement T3’ but its text was ‘T3’”.
Indeeed, when I delete the local storage et refresh the page, the locator contains “T3”. After un another refresh, the data “Appartement T3” is displayed.
My questions :
Is it the good way to work with Angular for the test ?
If Yes, how can I verify data ? Add an another step which refresh the page ?
Someone smarter than I will surely eventually chime in to help you out as I don’t have a lot of experience with Angular. But why is it that you have to refresh the page so that the text changes from ‘T3’ to ‘Appartement T3’? Is there some sort of caching going on? Ideally you shouldn’t have to constantly be refreshing a page, if anything, I think doing so would result in more buggy and flaky tests.
Before you do your assertion with the *Contains keyword, are you waiting for that element to be visible and/or enabled? Maybe it is a timing/synchronization problem going on. This is using SeleniumLibrary right?
Thank you for your answer.
Indeed, I have forgot that when the browser opens itself, it’s a new profile without cache… And the choice cookie’s windows opens too.
The issue is just the acceptation of this windows and put a “sleep” time during the loading of the data.
usually it’s better practice to use a wait for element type syntax than a simple sleep.
This is because you usually need to set the sleeps to a large number or they will still fail intermittently but if you set them to a large value and you have a large number of tests with these large sleeps you end up having your test suite taking a very long time to run.
Simply using a wait for statement means you can set a large time out 300+ seconds, if the page is slow the test won’t fail but the test will only wait as long as needed, so when the page takes less than 1sec the test continues quickly.
How long is too long for a time out? for performance testing we use 600 sec, for regression testing it depends on your organisation.
I use “Sleep” because when I used “Set brower implicit wait” for example, I had notice that the behavior wasn’t the one I was waiting for. Perhaps because I have a wrong use of it ?
My settings of “Sleep” has a maximum of “5”
What I did for my project using angular, I created a keyword that works great for me, no stability issues for last few months with over 600 tests, running at least once per day.
Wait for page to load
FOR ${i} IN RANGE 1 500
${var} SeleniumLibrary.Execute Javascript try { return ((window.angular.element(document.querySelector('body')).injector().get('$http').pendingRequests.length) === 0) } catch (SyntaxError) { return true}
Exit For Loop If ${var}
Sleep 10ms
END
And also I created a custom Click keyword, that I use instead of the Selenium LIbrary Click Element one, like this
Click
[Arguments] ${locator}
SeleniumLibrary.Click Element ${locator}
Wait for page to load
SeleniumTestability is a plugin to SeleniumLibrary, where its main motivation of existence is to help out with exactly these sort of issues. It has similar approach as Protracker except its not angular only.
It monitors events of the SUT (your app) and knows when its not performing any actions that can modify the DOM as a result. It monitors animations too and other stuff … And will provide you automatic waits until either the timeout has occured or the SUT state is idle.
This means: for example if the application is doing something, for example, in angular’s case if the SUT has requests on going, ST will automatically wait for those to resolve when using any calls that ends up doing locator queries - essentially eliminating any explicit sleeps/waits in most of the cases. Only service workers are not supported…