6

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?

poupou
  • 43,413
  • 6
  • 77
  • 174
asp_net
  • 3,567
  • 3
  • 31
  • 58

1 Answers1

8

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.

poupou
  • 43,413
  • 6
  • 77
  • 174
  • Thanks for your reply (btw. I just wrote you an email a few minutes ago about compiling Touch.Unit by myself ;)). I know that Touch.Unit isn't about UI testing, what I meant was what you described in a better way, especially dependencies from monotouch.dll. I don't have that dependencies in my current system under test, so I was surprised by struggeling around that much. Managing classes in two kinds of projects seems to be a good way. Thanks for your advice. – asp_net Sep 11 '12 at 14:26