Best way for Unit Testing MonoTouch Projects?

Question

Is there actually a good way to unit test MonoTouch projects using NUnit and the MonoDevelop test runner?

I know there is the official MonoTouch unit tests project type, but running tests within the simulator isn't the way I want to go. For now I want to run tests with the MonoDevelop test runner, later everything should work with Jenkins (CI).

I know the limitations about UI specific code, so everything I want to test has nothing to do with MonoTouch itself, it's all about business logic placed within separete projects.

By adding tests to MonoTouch Library type projects, I am getting System.IO.FileNotFoundException's as described here: http://ben.phegan.name/index.php/2011/02/28/monotouch-and-unit-testing/

By using a separate NUnit test project, I can't reference my system under test, because its project type is of type MonoTouch library project, which, of course, has an incompatible target framework (vMonoTouch).

So, there isn't any real alternative to Touch.Unit, is it?

Answer 1

Is there actually a good way to unit test MonoTouch projects using NUnit

Touch.Unit

and the MonoDevelop test runner?

Not really. MonoTouch projects depends on monotouch.dll which needs to execute under iOS (not OSX). So there's a need for the runner to execute on the simulator or devices.

Now there's a few misconceptions in your question:

later everything should work with Jenkins (CI).

Touch.Unit is already used with continuous builds / integration servers (as long as they are running OSX) using both the iOS simulator and/or devices. Details are available here.

I know the limitations about UI specific code,

Touch.Unit is not about UI testing. In fact it's pretty bad at UI testing (but that's beside the point).

Touch.Unit is a test runner that execute on iOS. That allows you to use MonoTouch / iOS API inside your own tests (it could be UIKit, but it could be StoreKit, GameKit, *Kit, any Foundation class... it's a quite large world).

So, there isn't any real alternative to Touch.Unit, is it?

Yes. If your business logic is well isolated and does not depend on monotouch.dll then you should be able to build it either as:

• a non-MonoTouch project (different project, same sources), i.e. linked with the regular framework; or
• link to the sources from within your unit test assembly (which links to the regular framework);

That classic nunit test assembly would then be a regular framework project and will be able to run from the default NUnit runner or from within MonoDevelop unit test runner.