A blog about one man's journey through code… and some pictures of the Peak District

Monthly Archives: March 2015

Coded UI Tests are something I’ve always thought would be useful, but have only recently actually used. This post is details of the first issue that I came up against.

The Problem

When you record a Coded UI test, you tell VS you want to do so, run whatever application that you want to test, and then record a series of tests; usually this means clicking the screen. Here’s what one of the UI projects looks like after you finish recording:

The recording that generated this was a quick test of a codeplex project of mine called TFS Utils.

My initial thought about this was: what happens when the buttons move around the screen, or the resolution changes. So I tried both of those things… and it still works. The points above are relative; what’s more: they are optional. The following is the same code, copied over to UIMap.cs and the points removed.

Since this Point seemed effectively pointless, I had a look around, and it turns out there is a reason; which is for menu buttons, where you need to specify a particular point within the button; rather than just anywhere. I would argue that the default recording should be what’s above, as it seems cleaner. I’m not strictly sure who I would argue that with though.

Disabled Controls

If you look at the menu in the project referenced, you’ll see that the menu items enable only when the URI is validated. This took me a while to work out; because if it’s not available, it just breaks the test:

Admittedly this isn’t my usual type of post. However, I’ve had a number of occasions where the touchpad on my Toshiba Satellite L855-188 has stopped responding.

When I say that it doesn’t respond, it actually behaves in a bazaar way: the mouse acts as though the machine were incredibly busy (an occasional jerky movement every few minutes – yes minutes). However, if you hold a mouse button down, it works fine (that is, the mouse responds correctly – obviously trying to navigate Windows with a mouse button constantly pressed presents its own problems).

In it, Stuart Lodge describes a manual mock to replace the `IMvxMainThreadDispatcher`. I’ve recently started using RhinoMocks again, and the following is basically the manual mock described in the above article, in RhinoMocks:

The first issue I encountered with Windows Phone was the volume. Having maxed out my laptop speakers, I managed get a faint whimper. What I finally deduced is that, for some reason, when the emulator starts, it starts at half volume. To increase it you have to press the phone’s volume buttons (which I initially assumed were just there for aesthetics. Clearly Microsoft haven’t entirely abandoned skeuomorphism.

The volume controls are the top right buttons (which I happened to know because I have owned a Windows Phone in the past). Once you press it then a more sensible interface appears and you can change either the ringer volume, or the game volume.

Overtalking

Although the code above does work, try calling the code in a loop (or just twice). What happens is that it doesn’t wait for itself to finish.

What I didn’t realise (until I asked this) was that there are some events which supposedly fire when the media element has finished playing.

I say supposedly, because when I first tried to capture the events, they did nothing. After a bit of searching, it turns out that the element needs to be part of the visual tree! Which of course makes total sense – an AUDIO media element must be part of the VISUAL tree.

In the Visual Tree

The code below now looks for the media element in the visual tree, and if it can’t find one, adds it. It also uses the TaskCompletionSource object to await the audio stream.

That works. At least, it works on Windows Phone. Because it uses a media element, I thought putting it on a shared XAML page would work… but it doesn’t. Windows 8.1 just sits there quietly and says nothing.

Windows Store

After much trial and error, it occurred to me (prompted by a comment on the above question) that if the problem was down to a deadlock, then destroying and recreating the control might clear this up.