¿La mejor manera para probar unidades de proyectos MonoTouch?

Question

¿Existe realmente una buena forma de probar unidades de proyectos MonoTouch usando NUnit y el corredor de pruebas MonoDevelop?

Sé que existe el tipo de proyecto de pruebas de la unidad MonoTouch oficial, pero ejecutar las pruebas dentro del simulador no es la forma en que quiero ir. Por ahora quiero ejecutar pruebas con el corredor de prueba MonoDevelop, luego todo debería funcionar con Jenkins (CI).

Conozco las limitaciones sobre el código específico de UI, por lo que todo lo que quiero probar no tiene nada que ver con MonoTouch, se trata de lógica de negocios colocada dentro de proyectos independientes.

Mediante la adición de pruebas para proyectos de tipo Biblioteca MonoTouch, estoy consiguiendo de System.IO.FileNotFoundException como se describe aquí: http://ben.phegan.name/index.php/2011/02/28/monotouch-and-unit-testing/

Mediante el uso de un proyecto de prueba NUnit por separado, no puede hacer referencia a mi sistema bajo prueba, ya que su tipo de proyecto es del tipo proyecto de biblioteca MonoTouch, que, por supuesto, tiene un marco de destino incompatible (vMonoTouch).

Entonces, no hay una alternativa real a Touch.Unit, ¿o sí?

Answer 1

¿Existe en realidad una buena manera de proyectos MonoTouch de pruebas unitarias utilizando NUnit

Touch.Unit

y el corredor de prueba MonoDevelop?

Realmente no. Los proyectos MonoTouch dependen de monotouch.dll que necesita ejecutarse bajo iOS (no OSX). Por lo tanto, es necesario que el corredor ejecute en el simulador o dispositivos.

Ahora hay algunas ideas falsas en su pregunta:

después todo debería funcionar con Jenkins (IC).

Touch.Unit ya se utiliza con servidores continuos de compilación/integración (siempre que estén ejecutando OSX) utilizando tanto el simulador iOS como los dispositivos. Los detalles están disponibles here.

sé las limitaciones sobre el código específico de interfaz de usuario,

Touch.Unit es no acerca de las pruebas de interfaz de usuario. De hecho, es bastante malo en la prueba de UI (pero eso no viene al caso).

Touch.Unit es un corredor de prueba que se ejecuta en iOS. Eso le permite usar MonoTouch/iOS API dentro de sus propias pruebas (podría ser UIKit, pero podría ser StoreKit, GameKit, * Kit, cualquier clase Foundation ... es un mundo bastante grande).

Por lo tanto, no hay una alternativa real a Touch.Unit, ¿verdad?

Sí.Si su lógica de negocio está bien aislada y no depende de monotouch.dll, entonces debería ser capaz de construir, ya sea como:

• un proyecto no MonoTouch (diferentes proyectos, mismas fuentes), es decir, ligada a la marco regular; o
• enlace a las fuentes desde el interior del conjunto de prueba de la unidad (que enlaza con el marco normal);

Eso conjunto de prueba nunit clásica sería entonces un habitual proyecto marco y será capaz de ejecutar desde el predeterminado corredor NUnit o desde dentro corredor de prueba unidad de MonoDevelop.