特殊なプラットフォームで今も問題となっているのが，ユニットテストのサポートの欠如である。どのような方法を選択しても，開発者はテストあるいはビルドプロセスの品質に関する妥協を余儀なくされる。最近になって MonoTouch がこの分野で進歩を遂げたが，Windows Phone と Mono for Android はいまだ遅れを取っている。
Windows Phone 7 / Silverlight
Windows Phone 7 には，開発者が利用可能な２つのテストルートがある。ひとつは Silverlight ユニットテストフレームワークをハックして，Windows Phone デバイス上で動作させるというものだ。Silverlight 開発者の多くはすでに，このようなやり方には馴染んでいる。ユニットテストフレームワーク自体が "試験的 (experimental)" と公表されていて，少なからぬ数のテストのサポートに手を加える必要があるからだ。Jeff Wilcox 氏は Silverlight 3 と Windows Phone 7.0 でユニットテスト を行うための，そのような修正版のひとつを提供している。
良い点: 他の選択肢に比較して，より正確なテストの実施が可能。
悪い点: ビルドプロセスに含めることができない。IDE サポートがない。
Christofer Löf 氏は，まったく違う方法を選択した。まともなテストフレームワークを Windows Phone に押し込もうとするのではなく，テストしたいコードをそこから引っ張り出すことにしたのだ。氏は Portable Library Tools を使って独自のモデルとビューモデルを実装することにより，標準的なユニットテストフレームワークとデバイス上の両方で，同じコードの実行を実現した。ただし残念なことに Portable Library は，"ListFactory" を使用時に適切なタイプを提供するために必要な observable collection (更新時に通知を行うコレクションクラス) をサポートしていない。
良い点: ビルドサイクルの一部として組込可能。 任意の標準的ユニットテストフレームワークに対応。IDE 統合。
悪い点: Portable Library Tools で利用可能な API が限られている。
第３の方法は，同じソースコードを共有する別プロジェクトを使用することだ。コードが完全に同一であれば理想だが，ほとんどの差異には，プリプロセッサディレクティブを使用して対処することができる。独立したビルドの必要な MonoTouch と Mono for Android ですでにコードを共有しているか，あるいはそれを計画しているのならば，このアプローチがもっとも理にかなっている。
良い点: ビルドサイクルの一部として組込可能。 任意の標準的ユニットテストフレームワークに対応。IDE 統合。
悪い点: ビルド処理時間の増加。プラットフォーム間の相違による問題の可能性。
iOS / MonoTouch
MonoTouch には最近になって，オンデバイスのユニットテストフレームワークが追加された。Windows Phone バージョンとは違い，こちらには公式なサポートがある。この Touch.Unit フレームワークの本質は，MonoDevelop 用に基本的な IDE サポートをいくつか備えたテストランナである。その中心をなすのは，デバイスの限られたリソースで動作するように修正された NUnit フレームワークのサブセットである NUnitLite だ。
良い点: 他の選択肢に比較して，より正確なテストの実施が可能。
悪い点: ビルドプロセスに含めることができない。IDE サポートがない。
Touch.Unit がリリースされるまで，開発者は Windows Phone の場合と同じように，ソースコードを共有する別プロジェクトを使用していた。ただしこの場合には当然，Microsoft のランタイムに代えて，Mono のフルセットランタイムと NUnit がターゲットになる。
良い点: ビルドサイクルの一部として組込可能。 IDE 統合。
悪い点: ビルド処理時間の増加。プラットフォーム間の相違による問題の可能性。
Android / Mono for Android
現在のところ，Mono for Android プロジェクト用ユニットテストの唯一の選択肢は，複数のプロジェクトを使用する方法だ。Mono for Android は MonoTouch ほど製品として成熟していないが，将来的には同等のテストフレームワークが用意されることになるだろう。