Robot tests: wait until overlay is closed.

[mauritsvanrees]

Use the correct selector to check for the overlay: it is no longer div.overlay, but div.modal-wrapper.
Wait only 8 seconds instead of 60 for this check to be true.
Also use 'Wait For Then Click Element' for good measure.

This is an attempt to make robot tests more stable
I still sometimes see a test fail, becase the popup/modal/overlay is still open after clicking a button. This might fix it.

Update: no it does not. But the updated checks at least make it clear that a popup is still open, which is the reason why some other expected text is not visible.

Sample from "Capture Page Screenshot" for a failed test:

This looks exactly like I expect it to, except that the modal should have closed because the button has been clicked.

[mauritsvanrees]

BTW: at this moment the Jenkins front page is completely green! Well, except for the Python 3.10 jobs.

[mauritsvanrees]

I do wonder if https://pypi.org/project/robotframework-seleniumtestability/ would help here. Fred found that via Asko.

[petschki]

This package sounds promising!

[mauritsvanrees]

Python 3.8 PR robot tests fail with:

"Keyword 'Page should not contain element' failed after retrying for 8 seconds. The last error was: Page should not have contained element 'css=div.modal-wrapper'."

So there is a failure, but at least it is a clearer one. I call success and merge this.
To be continued.

[fredvd]

@mauritsvanrees @petschki Asko created a pull request here yesterday: plone/plone.app.robotframework#137

I checked the testability package locally, but it is not a magic wand

• as Asko notes in that PR he sees local javascript errors, I saw some webdriver errors
• there is no real output to see 'when' the testability actually saves you/does something
• Asko suggested a variables way to enable testabilty per robot file which we have to test, otherwise it's 'always on' because you have to register the library in p.a.robotframeworks 'main' robot file.

I created to 2 local branches of p.a.robotframework and Products.CMFPlone to test this plugin later with the pull request job on jenkins to see if it helps, but we're already 'almost' to green again with the robottests. I'll continue with that later today, got side tracked with other work.

In this particular test it is interesting to see if the xhr request/post from the modal maybe prevents it from closing in time and if the testability plugin would catch this and pause the robot commands for a while.

[petschki]

keep in mind, you have to pin the extra packages in buildout.coredev as asko mentioned ...

[fredvd]

Yes I'm aware of those, I was wondering yesterday first where the furl package was coming from when we also tested the minor/patch updates of selenium itself. but it was this package.