Error when clicking on RadMenuItem as DesktopElement

[Qays]

Dear Telerik team, 

we have discovered an issue with context menu operations. Here's a simplified code example clicking a menu item. The problem is that the click is performed on a different entry way below the one accessed in this code. Is that a bug? 

Furthermore, is there a way to access the context menu item directly with a click operation?  

Or maybe, is there a better way to access the context menu from code? Parsing through the VisualTree immediately closes the context menu.

  
var desktop = DesktopElement.FromDesktopRoot();
 
 // open context menu
 @this.User.lick(MouseClickType.RightClick);

 // get context menu
 var contextMenu = desktop.Find.ByClassName("RadContextMenu");

 // get entries
 var entries = contextMenu.Find.AllByClassName("TextBlock").As<DesktopText>();
 entries.First(box.Text == menuItem).User.Click();

 

Best regards!

[Elena]

Hi Qays, 

There are a couple of additional details to sort out for the discussed issue. Please, let me know your input on the below topics: 

1. What type application you are testing? 
2. What is the reason to choose a coded approach of automating the context menu?
3. Why do you use the Desktop framework to find the element? (applicable only in the case you automate a web or WPF app) 
4. Did you tryu record the actions and whaw the outcome? 

I wanted to add few notes about your query for the DOM tree and context menu items: This control is always a challenge because context menu usually require focus and sometimes thiese may not work very well with the Test Studio hihglighting menu which also needs the focus. Let's check if this is the case on your end as well. 

Please, check this KB article and try the suggested solutions. Let me know what is the outcome of these and if you see any steps recorded.

Thank you for your cooperation in advance.

Regards,
Elena

[Qays]

Hi Elena,
we will check it and give you our feedback...

[Elena]

Hi Qays, 

Take your time and let me know in case of additional questions.

Regards,
Elena

[Qays]

Hi Elena,

1. We are writing tests for a WPF application that uses browser and CAD plugins. 

2. Our software has a very dynamic user interface with dynamic context menus. Recording steps is too error prone for our usecase. Furthermore we can't assert the correctness of the menu entries with recorded steps. Using code on the other hand works very reliably and a lot faster. 

3. Trying to access the context menu as FrameworkElement resulted in closing the context menu instead of accessing it. Therefor the DesktopElement approach.

4. Yes. Performing a recorded context menu click works fine, yet a nested context menu which reacts to mouse hover leads to a comparable behavior: the first menu entry cannot be clicked. 

Concerning the article in your link: 
Freezing the DOM explorer while the context menu is open, causes the context menu to close. 

Using code was a well considered decision by our testers and developers. 

I hope these answers helped. So, why does the click on an element result in a click action on a very different one? Furthermore, is there a way to click the RadMenuItem instead of its child (TextBlock) element?

 

Regards

[Qays]

Hi Elena,

we have found a hint for the reason behind that misplaced click: It seems that this false behavior is linked to the desktop solution. On one screen (2560x1600) the expected error occured. On the other screen (1920x1080) the context menu handling worked as expected.

[Elena]

Hi Qays, 

Thank you for sharing thorough details for the specifics of the application you work on - these are really helpful for me.

So, first thing to say is that Test Studio WPF tests recognize only the WPF components and cannot interact with the embedded browser, for example. So, I completely understand the need of using the Desktop capabilities of the Testing Framework - this is also what we recommend in similar cases.

First thing to mention is about the KB article I shared along - it represents an approach to get the elements of the context menu in the DOM explorer, so that you can use these to add steps while in recording mode. Freezing the DOM while the context menu is opened stops the autorefresh of the DOM and thus keeps the Explorer tab showing the state of DOM tree with the elements of the context menu within. It is meant to ease the recording for such scenarios. 

Next thing to add is about handling complex and dynamic context menus with sub-menus - I can recommend a couple options to explore when it comes to the recorded steps and elements. 

• Using the MouseHover step to simulate the same user action. It is also available in the Step builder for adding steps using already recorded elements without a recording session.  
• The above can be used in combination with freezing the DOM in certain state.
• Check what find expressions are using the elements recorded for the actions in the context menus. If it is suitable to use their text content or inner text, you might find useful to data drive the elements find expressions and handle the multiple available options across the sub-menus that way. 

And last note is about the display resolution - it is a must to use the same display settings when it comes to WPF and Desktop testing. In most cases the same is valid for web testing as well, but a web page is more flexible in rendering its content. 

I hope this information is of further help for you. Let me know in case you have additional questions. 

Regards,
Elena