Best way to test Microsoft Surface

Question

Recently, I was developing Microsoft Surface applications. I also read something about how these applications can be tested.

I am currently using unit tests (Microsoft.VisualStudio.TestTools.UnitTesting package) to test the low-level functionality of individual methods. The user interface I'm testing with the Surface Simulator API. For both approaches, I always create an additional project in the same solution.

But I'm not sure if this is really a good approach. Testing modules is more or less normal, but tests for the user interface are more or less limited by clicking on various things and checking for errors. Although this check is not performed explicitly.

So, I ask, are there any other approaches to beneficially testing the Surface app?

Answer 1

Here's how to do it in the Surface command: The Simulator APIs included in the Surface SDK will allow you to automate sending fake touch input to your application. Combine this with the WPF Automation Peers to automate verifying that your interface is working correctly. For Surface controls that come from standard WPF controls, you can use the AutomationPeer classes that ship with WPF. For surface-specific controls such as ScatterView, the Surface SDK includes its own set of AutomationPeer classes.

If you are not familiar with automation experts (and most people), here is a good introductory blog post on the topic: http://miketwo.blogspot.com/2007/03/unit-testing-wpf-controls-with.html

Answer 2

The best way to test the Surface app is to install it on a real table and use it. Even better, let other people use it and look at them. Check the behavior of applications when it opens again from the menu, from the tag, when several people use it, when the Internet connection goes down, etc. Some interactions are easier when you're the only user using the mouse and keyboard.

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