Reliable clicking: by implementing click open, click close keywords

[noubar]

After years of experience. It is clear that the ui automation is easier said than done. The biggest issue we are facing is the timing issue of ui element initialization. The click is done by robot and the next keyword is executed without waiting. But after the click the reaction may have not be ended successfully so the test fails, because of milliseconds even we have built timeout and repeated clicking internally. Building sleeps in the robot test is not a good way to avoid such issues. But to wait for the reaction of the click. So Within this issue i am apposing to implement couple new keywords.

Click Open Click Close Right Click Open Right Click Close Double Click Open Double Click Close

These keywords gets two xpath rather than one. First xpath the element to be clicked the second an element to be opened or closed>

Further optional arguments will be. Focus Element before open/close Focus Element after open/close Max repeating times == 5 Timout for each repeat == 1 (seconds) Ignore if already open/close == True

[Nepitwin]

@noubar

Well i know why you want to implement these kind of keywords ;) Yes it make sense to implement such a kind of keywords.

Pls implement these keywords by use all module methods usage in Keywords module side because you can call all executions on this side. It's a good enhancement to make click operation more stable.

[noubar]

@Nepitwin I need some additional eye and help i cannot see the pattern why the test case is failing. The problem is in https://github.com/GDATASoftwareAG/robotframework-flaui/blob/147-new-keywords-reliable-clicks/atests/Mouse.robot#L105

I am getting the error

Expected error 'FlaUiError: Element '/Window[@Name='FlaUI WPF Test App']/Window/Menu/MenuItem[@Name='Some MenuItem']/Text[@Name='Some MenuItem']' could not be closed after clicking on '/Window[@Name='FlaUI WPF Test App']/Tab/TabItem[@Name='Simple Controls']/Button[@AutomationId='PopupToggleButton2']'' but got 'FlaUiError: Element '/Window[@Name='FlaUI WPF Test App']/Window/Menu/MenuItem[@Name='Some MenuItem']/Text[@Name='Some MenuItem']' could not be closed after clicking on '/Window[@Name='FlaUI WPF Test App']/Tab/TabItem[@Name='Simple Controls']/Button[@AutomationId='PopupToggleButton2']''.

Expected "ABC" but got "ABC" Both strings are identical but still failing. I've got around the issue in the previous test case by adding STARTS: as prefix which will not compare for absolute equality.

[noubar]

I am doing something wrong but where?

[Nepitwin]

@noubar

Kind of strange by Diff Checker he identifies differences

If you compare

Expected error

'FlaUiError: Element '/Window[@Name='FlaUI WPF Test App']/Window/Menu/MenuItem[@Name='Some MenuItem']/Text[@Name='Some MenuItem']' could not be closed after clicking on '/Window[@Name='FlaUI WPF Test App']/Tab/TabItem[@Name='Simple Controls']/Button[@AutomationId='PopupToggleButton2']''

but got

'FlaUiError: Element '/Window[@Name='FlaUI WPF Test App']/Window/Menu/MenuItem[@Name='Some MenuItem']/Text[@Name='Some MenuItem']' could not be closed after clicking on '/Window[@Name='FlaUI WPF Test App']/Tab/TabItem[@Name='Simple Controls']/Button[@AutomationId='PopupToggleButton2']''.

By notepad it's not equal. But i don't see the charecter which is different

[Nepitwin]

Left one does not contains a dot and ends by a whitespace. Right one ends by dot.

Potential the dot at the end?

[noubar]

Nope it is not. Those are added by the robot logger

[noubar]

I have tried the test case with try and catch instead of run keyword and expect error and it is working fine. Which means the internal comparison in run keyword and expect error has some issues processing characters in this case. Because with prefix of 'STARTS:' is working fine. I am setting the Prefix EQUALS: instead and it is also working fine. I think there is a combi of character order in the error text triggering some wildcard search internally in the keyword and according to documentation EQUALS: prefix disables wildcards. So the test should fine now.

What i am surprised for that we have never seen such a case with all other error text with xpaths in other unit tests.

[noubar]

@Nepitwin Thank you for your contribution but before i close this issue I still want to change close_elment argument of click close to optional by setting a default value for close_element = click_element. i will make a new PR with the changes

[noubar]

And after testing i will be adding the other intended keywords Right Click Open Right Click Close Double Click Open Double Click Close