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?
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
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.