目前具体平台的一个问题是缺乏单元测试的支持。开发者被迫在测试的质量和构建流程之间做出妥协，以便一切能够工作起来。最近MonoTouch在这个方面取得了进展，但Windows Phone和Mono for Android仍然落后。

　　Windows Phone 7/Silverlight

　　Windows Phone 7的开发者可以通过两个途径进行测试。第一个是修改Silverlight单元测试框架，使之能够运行在Windows Phone设备上。许多Silverlight开发者已经对此熟悉，这个单元测试框架本身还在“试验阶段”，修改需要支持大量测试。Jeff Wilcox为Silverlight 3和Windows Phone 7.0的单元测试提供了一个修改。

　　利处：提供的测试比其他选择更加精确。

　　弊处：不能包含到构建流程里，没有IDE支持。（译注：CodePlex上有个Windows Phone Essentials的开源项目提供了Visual Studio测试项目模版，支持通过NuGet安装，能和Jeff Wilcox修改的单元测试框架一起工作。）

　　Christofer L？f采用了完全不同的途径。他不是把一个测试框架放到Windows Phone里，而是把他要测的代码拿出来。通过Portable Library Tools实现他的模型和视图模型，他可以在标准的单元测试框架以及设备上运行相同的代码。不幸的是，Portable Library并不支持ObservableCollection，需要使用“ListFactory”提供正确的类型。

　　利处：可以包含到构建流程里，可以使用任何标准单元测试框架，支持IDE整合。

　　弊处：Portable Library Tools只提供有限的API。

　　第三个途径是使用单独的项目共享相同的源代码。在理想情况下，代码是一样的，但可以通过预处理器指令处理大部分差异。如果你打算在MonoTouch和Mono for Android上共享相同的代码，这种做法就很有意义了，因为它们需要分开构建。

　　利处：可以包含到构建流程里，可以使用任何标准单元测试框架，支持IDE整合。

　　弊处：构建时间更长，平台之间的差异可能带来问题。

　　iOS/MonoTouch

　　MonoTouch最近有了一个在设备上执行的单元测试框架。和Windows Phone版本的不同，这个是官方支持的。Touch.Unit框架本质上只是一个测试执行器，并为MonoDevelop提供了基本的IDE支持。它的核心是NUnitLite，NUnit框架的一个子集，专门为有限资源的设备量身定做的。

　　利处：提供的测试比其他选择更加精确。

　　弊处：不能包含到构建流程里，没有IDE支持。

　　在Touch.Unit发布之前，开发者需要使用单独的项目共享相同的源代码，就像Windows Phone那样。不过，在这里他们将会使用完整的Mono运行时和NUnit而不是微软的相关平台和技术。

　　利处：可以包含到构建流程里，支持IDE整合。

　　弊处：构建时间更长，平台之间的差异可能带来问题。

　　Android/Mono for Android

　　目前为Mono for Android项目做单元测试的唯一选择是使用多个项目。Mono for Androidhi阿不够MonoTouch成熟，但最终我们应该可以看到一个类似的测试框架。