Unit Testing on Mobile Devices with .NET/Mono

Posted by Jonathan Allen on Feb 17, 2012

Sections

Development

Topics

MonoDroid ,

MonoTouch ,

Mono ,

Unit Testing ,

.NET ,

Android ,

iOS ,

TDD ,

Windows Phone 7 ,

Operating Systems ,

iPhone ,

Mobile ,

iPad ,

Programming ,

Testing

Share |

RELATED Research

An ongoing problem with specialized platforms is the lack of support for unit testing. Developers are forced to compromise the quality of their tests or their build process in order to get anything working. Recently MonoTouch has made progress in this area, but Windows Phone and Mono for Android still lag behind.

Windows Phone 7 / Silverlight

For Windows Phone 7 there are two testing routes available to developers. The first is to hack the Silverlight unit testing framework so that it will run on a Windows Phone device. Many Silverlight developers are already familiar with this, as the unit testing framework itself is advertised as “experimental” and modifications are needed to support a non-trivial number of tests. Jeff Wilcox provided one such modification for unit testing Silverlight 3 and Windows Phone 7.0.

Pro: This offers more accurate tests than the other options.
Con: Cannot be included in the build process. No IDE support.

Christofer Löf went took a completely different route. Rather than trying to push a decent testing framework into Windows Phone, he pulled the code he wanted to test out of it. By using the Portable Library Tools to implement his models and view-models he was able to run the same code under a standard unit testing framework as well as the device. Unfortunately the Portable Library doesn’t support observable collections, necessitating the use of a “ListFactory” to provide the correct type.

Pro: Can be included as part of a build cycle. May be any standard unit test framework. IDE Integration.
Con: Limited API available through Portable Library Tools

A third method is to use separate projects that share the same source code. Ideally the code will be identical, but preprocessor directives can be used to smooth over most differences. This approach makes the most sense when you will are already planning on sharing the same code with MonoTouch or Mono for Android as they would need separate builds.

Pro: Can be included as part of a build cycle. May be any standard unit test framework. IDE Integration.
Con: Longer build times. Differences between the platforms may be problematic.

iOS / MonoTouch

MonoTouch recently gained an on-device unit testing framework. And unlike the Windows Phone version, this one is officially supported. The Touch.Unit framework is essentially just a test runner with some basic IDE support in MonoDevelop. At its core is NUnitLite, a subset of the respected NUnit framework tailored to fit on limited resource devices.

Pro: This offers more accurate tests than the other options.
Con: Cannot be included in the build process. No IDE support.

Prior to the release of Touch.Unit, developers would use separate projects that share the same source code much as we see for Windows Phone. But of course in this case they would target the full Mono runtime and NUnit instead of the Microsoft alternatives.

Pro: Can be included as part of a build cycle. IDE Integration.
Con: Longer build times. Differences between the platforms may be problematic.

Android / Mono for Android

Currently the only option for unit testing Mono for Android projects is the multiple-project option. Mono for Android is a less mature product than MonoTouch, but eventually we should see it getting a comparable testing framework