0

I'm using CodedUI in WPF, Visual Studio 2013, using a combination of the built in tools, and hand written tests.

I'm trying to click a basic button on a popup window. I have similar windows that work fine, from external libraries, however this is from my own.

Mouse.Click(UIMap.StubWindow.OK);

This creates an error, as it cannot find the OK button. Additionally calling:

UIMap.StubWindow.DrawHighlight();

Fails also, not being able to find the window. However sometimes it draws an outline around the Start Button in Windows. Strangely, both of the below lines work correctly, after calling FindMatchingControls().

UIMap.StubWindow.FindMatchingControls();
UIMap.StubWindow.DrawHighlight();
Mouse.Click(UIMap.StubWindow.OK);

The problem is, it takes around 5-10s for FindMatchingControls to execute, as it has to search all top level windows on the system. Even after matching one window. Calling Find(); does not work. However oddly, 

var x = UIMap.StubWindow.FindMatchingControls().Count;

x is 1.

Is there a reason for this, or a way for me to not need to call FindMatchingControls? I have tried changing the search configurations to always search for both the window and the OK button, but that does not work.

SearchProperties is relying on an AutomationId, and a Framework ID, both using the EqualsTo operator.

This does not work even when used directly from the test builder. I only found that FindMatchingControls makes it work whilst debugging, checking for ambiguity.

MetalMichael
  • 130
  • 2
  • 10
  • Your question has too many pieces. What is `DrawOutline` and did you mean `DrawHighlight`? For ideas on some points see http://stackoverflow.com/questions/19962011/cant-determine-if-a-certain-uitestcontrol-exists-in-my-web-app/19966000#19966000 and http://stackoverflow.com/a/27527105/546871 and http://stackoverflow.com/a/19304760/546871 – AdrianHHH Sep 03 '15 at 12:32
  • Sorry, yes, I meant DrawHighlight. As simply as possible: Window doesn't exist when referencing directly. Using FindMatchingControls first means that it then is found. Unsure why. Should be a direct unambiguous match. – MetalMichael Sep 03 '15 at 12:59
  • You said that sometimes it draws a highlight around the **Start** button. So how do you know that `...FindMatchingControls().Count` is finding the **OK** button as opposed to finding the **Start** button? – AdrianHHH Sep 03 '15 at 14:00
  • I don't. All I know is that the highlight and click functions work afterwards. I also tried a wait, to see if the reason that they were working afterwards was because of the time spent searching. This was not the case. – MetalMichael Sep 03 '15 at 14:13
  • I suspect it could be because of a popup. Coded UI tries to find the OK button even before the ui thread is updated to the popup. So this works sometimes depending on which acted first. If UI thread switching happens quickly then codedui can find the control. This could also explain why it is able to find while debugging because ui thread would swicth to popup before we debug next statement. You can try to set `Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads` but then again this would slow everything down. – SarkarG Sep 06 '15 at 16:53

2 Answers2

1

Just fixed this. Seems fairly obvious now, but the popup windows were written quickly and didn't have titles.

Didn't notice/think this was important, but had a fairly large impact. Added titles and setup the UIMap again, and works fine.

MetalMichael
  • 130
  • 2
  • 10
0

Have you tried defining the control w/o using the UIMap? Something like this?:

var app = new ApplicationUnderTest();
var x = new UITestControl(app);
x.SearchProperties.Add("Key","Value");
x.SearchProperties.Add("Key","Value");
x.SearchProperties.Add("Key","Value");

Mouse.Click(x,x.GetClickablePoint());
Drew
  • 66
  • 5