Best way to test a Microsoft Surface application

Question

Recently I was doing a lot of development in Microsoft Surface application's. I also read something about how these applications can be tested.

Currently I'm using Unit tests (package Microsoft.VisualStudio.TestTools.UnitTesting) to test the low level functionality of single methods. The user interface I'm testing with the Surface Simulator API. For both approaches I always create a extra project in the same solution.

But I'm not really sure if this is really a good approach. Unit testing is more or less ok, but the tests for the user interface are more or less limited by clicking various things and checking if there is no error. Although this checking is not really done explicitly.

So I'm asking are there any other approaches to beneficially test a Surface application?

Reichsmark

Answer 1

Here's how it's done on the Surface team: The Simulator APIs included in the Surface SDK will let you automate sending fake touch input to your app. Combine that with WPF's "Automation Peers" in order to automate validation that your UI is doing the right thing. For Surface controls that are derived from standard WPF controls, you can use the AutomationPeer classes that come with WPF. For Surface-specific controls like ScatterView, the Surface SDK includes it's own set of AutomationPeer classes.

If you're unfamiliar with automation peers (and most people are), here's a good introductory blog post on the topic: http://miketwo.blogspot.com/2007/03/unit-testing-wpf-controls-with.html

Erminia

Thanks. This sounds nice, I'll take a look at it. – Consonantal

I read the blog post and tried to used automation peer, but every time I try to instantiate a SurfaceWindow I get an exception: XamlParseException:'Provide value on 'System.Windows.Baml2006.TypeConverterMarkupExtension' threw an exception.' Line number '9' and line position '42'. Do you have a small example on how to use AutomationPeer with Surface? – Consonantal

no, sorry. you'll have to drop some breakpoints in any code that runs when your window initializes and step through to see where things are failing – Erminia

Yes I found the error: <ImageBrush x:Key="WindowBackground" Stretch="None" ImageSource="pack://application:,,,/Resources/bg1.tif"/> Every time I used pack://application – Consonantal

that would do it... you'll have to either add those resources to your test app as well or better yet, change the URIs to refer to the specific assembly instead of being relative – Erminia

But If I read here (msdn.microsoft.com/en-us/library/…) I'm already using absolute URIs instead of relative. – Consonantal

you need to edit the URI to refer to the specific assembly that the resources live in – Erminia

Answer 2

The best way to test a Surface application is to install it on a real table and use it. Even better, let other people use it and watch them. Test the applications behavior when it is re-opened from the menu, from a tag, when several people use it, when the internet connection goes down, etc. Some interactions are easier when you're the only user using mice and keyboard...

Of course this is complementary to unit testing and the simulator API, and probably more important in the early stages of application development, while prototyping, than later on.

Fungistat

Thanks. I did both of you're suggestions. I used the application a lot on a real device and I also had some other testers and potential users using it. But all these tests are not really ''quantitative''... So I'm looking for a more quantitative way. – Consonantal