Automated testing considerations for enterprise Windows Mobile projects - avoid a world of pain

I know in the past I have written blog posts on how to create unit tests that are actually executed on the Windows Mobile emulator which is great if you have mobile specific tests. But to be honest, when you are building large scale enterprise mobile solutions targeting a range of different devices i.e. Motorola, Casio, Intermec etc. Writing device specific platform tests for all these devices becomes quite hard to automate when using an application lifecyle management solution such as Visual Studio and TFS with its continuous integration and automated test execution support.

Even if you only support one type of device, when you do enterprise mobile development, using the tools mentioned above, you're not going to be able to automate those tests as part of a nightly build or even a CI build. As you will no doubt be using the vanilla Windows Mobile Emulators that know nothing about such specifics that you might be testing such as barcode reader, credit card reader, bluetooth stack etc. Instead you would normally write adapters or mock out implementation code when testing your barcode implementation. You'll generally never write an actual test that calls the true native code on that platform, why would you anyway unless it's part of an integration test. Ensuring you do this allows you to write unit tests, integration tests that do run as part of your nightly and CI builds that do improve code quality.

So what type of tests should you write for most of your code base, device or desktop? My advice is desktop even if you think your device project is small, there will come a time when your project becomes large and more complex. The benefit to targeting the desktop is the ability to use mocking frameworks. We tend to use Rhino Mocks and today there are 0 mocking frameworks available on the CF. If you start to go down to road of writing your own mocks, then you're entering a world of pain. When you think of it, most code can be tested on the desktop anyway. For things like data access, if you use SQL CE 3.5, then this can run on the desktop. For the features that require explicit device testing, then create a single device test project for this purpose and exclude it from the build definition.