Hello everyone!
My doubt regarding this is because I would like to find the best way to keep all three functions in a single keyword to save on code. I made three different attempts and would like your opinion on them and if you have any other better alternative.
First one:
Click Element ONE
[Arguments] ${element} ${timeout_visible}=5s
Wait Until Element Is Visible ${element} ${timeout_visible}
Scroll To Element ${element}
Click Element ${element}
Scroll to Element is a simple scroll function using javascript window.scrollTO
Second:
Click Element TWO
[Arguments] ${element}
Wait Until Keyword Succeeds 10s 1s Scroll To Element ${element}
Wait Until Keyword Succeeds 10s 1s Click Element ${element}
Third:
Click Element THREE
[Arguments] ${xpath} ${attempts}=10
${status} Set Variable ${False}
WHILE ${status} == ${False}
${status} Run Keyword and Return Status Click Element ${xpath}
${attempts} Evaluate ${attempts} - 1
Run Keyword If ${attempts} == 0 Fail ${xpath} not found
END
The third one I found here on the forum, so it’s not my own creation
Hi Pedro,
Click Element ONE would be my preference as the other 2 are likely to generate a lot of screenshots in your logs and might cause you disk space issues especially if you are using a cloud runner (docker, aws, etc) that has a small amount of disk space.
But this is just my personal opinion and preferences, so take with a grain of salt 
Dave.
1 Like
The scroll shouldn’t be necessary in the vast majority of instances as per the spec and the operational implementation of the webdrivers scroll to an element is done with every click. (I was going to add an exception here for infinite scrolls where elements only appear as one scroll down near them. If you have these even then this implemention you have of scroll to the element wouldn’t work because the element would not be there and instead one needs to scroll the page - not to an element). I agree with Dave that the second and third wait until keyword succeeds just adds a lot of logging. I am not sure about the usage of the visibility check in one either. Visible is a poor check for element interactable or more so test readiness. As I wrote in the slack channel a while back … [Visibility] has long been a fuzzy topic and visibility can mean many things. There is a fair amount written about this but most recently I came across this talk by David Bur - “Is It or Is It Not Really Visible; Selenium’s Flawed Vision”.
2 Likes
Hello Dave!!
I appreciate your opinion, I’m currently using the first one as well, as it’s better suited for the system I’m automating.
But regards the screenshots, it’s easy to disable and enable using Register Keyword To Run On Failure to prevent a lot of them
Thank you so much for your feedback, @EdManlove!
So I have a few inquiries I’d like to discuss:
In my situation, when I attempt to use only the Click Element command and the element isn’t visible in the browser window, it throws an “Element is not Interactable” error. This necessitates me to use a scroll keyword in page to interact with it. Any insights on this issue?
Thank you for sharing the video, I’ll watch it. Regarding the “Waiting Until Element is Visible” aspect, which method do you find most suitable or effective in your case? Could you share some examples of custom keywords you use, or do you rely solely on the default ones?
Hi Pedro,
It’s true you can disable and re-enable the screenshots, it just becomes a little more work, and adds the risk that you forget to re-enable them, but as Ed rightly pointed out it’s also more logging, plus more CPU & disk activity on the machine running the test (depending on your that may or may not matter to you).
There’s not really a right or wrong way, sometimes you have to do things in an odd way when you have apps that do weird things. I will say all three, grouping the steps in a keyword are better than just copy and pasting the same sequence over and over
Dave.