2010-02-20 9 views
6

Soy un gran creyente en las pruebas, pero no un muy buen practicante. He hecho bastante bien para obtener cobertura en mis objetos modelo y programarlos en un estilo TDD. Realmente lo estoy disfrutando tanto que me encantaría extender esto a mi capa de controlador, particularmente a mis subclases UIViewController.¿Cómo probar UIViewControllers en tiempo de compilación?

Desafortunadamente, muchas clases de UIKit no funcionan en pruebas independientes. Sin embargo, no estoy satisfecho con la restricción de solo ejecutar mis pruebas dependientes en el dispositivo. Es realmente importante para mí ejecutar todas las pruebas unitarias antes de cada construcción, y me parece que es posible y vale la pena probar la unidad (a diferencia de otros tipos de pruebas) del código controlador.

Mi pregunta es simplemente esta: ¿Cómo pruebo UIViewController s de tal manera que las pruebas se ejecutan antes de cada compilación? Conozco un par de soluciones diferentes a este problema, pero no sé mucho sobre los diversos beneficios de cada uno.

Respuesta

2

Así que no estaba contento con esta situación tal como estaba, y las respuestas de Daniel y Ed me estimularon a mejorar aún más las cosas. Decidí tomar el asunto en mis propias manos.

Lo que terminé escribiendo fue una pequeña aplicación Cocoa Touch que en -applicationDidFinishLaunching escanea la jerarquía de clases de cualquier subclase de SenTestCase y las ejecuta. A diferencia de las pruebas de unidad de GoogleToolboxForMac, intenté usar la mayor cantidad posible de la maquinaria SenTesting integrada y, como resultado, no terminé en ese código. No he realizado demasiadas pruebas más allá de verificar que UILabel asigna sin estrellar la plataforma de prueba (de hecho, se bloquea si lo intenta), pero debería funcionar.

He puesto la fuente en línea en Bitbucket y Github.

2

En general, si está atascado con un problema ambiental donde parece imposible hacer pruebas incondicionales, puede evitarlo si los beneficios son lo suficientemente buenos como para justificar su salto a través de algunos aros.

La situación aquí es un caso especial de dependencias externas no deseadas, que generalmente resuelvo en mis pruebas de unidad ya sea por #ifdesdecir pequeños bits de código dependiente, o implementando clases de stub para completar las funciones de dependencia esperadas lo suficiente como para que mi código puede ser probado.

En este caso específico, puede crear un nuevo archivo fuente, vinculado solo en el paquete de prueba, llamado "UIKitStubClasses.m" ... dentro de él puede implementar las necesidades básicas para simular clases dependientes de UIKit como UIViewController, por lo que tus pruebas se vinculen y ejerzan a fondo su propia lógica.

Lo importante a tener en cuenta es que, por lo general, esto no es necesariamente todo el trabajo. Las pruebas le permitirán saber qué debe implementar en el resguardo, por ejemplo emitiendo excepciones sobre métodos no implementados. Simplemente agregue lo que necesita para silenciar los errores y probar su código, y luego su clase de código auxiliar es lo suficiente como para probar como cualquiera de las clases legítimas del marco de sistema.

+0

Esto es probablemente lo que terminaré haciendo, probablemente. Sé que 'UILabel' y algunas otras clases no pueden asignarse cuando se ejecuta en un paquete de prueba unitaria, pero espero que pueda tener suficiente de esto funcionando. –

2

¿Puede usted no utilice los consejos/métodos en el blog de Chris Hanson aquí: http://chanson.livejournal.com/120263.html

Parece que es probable que tenga que ejecutar la aplicación como el instrumento de prueba, pero parece factible. El hecho de que esté ejecutando la 'aplicación' no significa necesariamente que deba hacer lo normal que hace su aplicación. Alternativamente, podría crear otro objetivo de aplicación que sea simplemente una aplicación ficticia simple que cargará sus paquetes de prueba y los ejecutará.

Acepto que podría no ser perfecto, pero parece que podría funcionar, y parece que podría automatizarse.

+0

No lo he probado, pero hasta donde yo sé este tipo de prueba no es compatible con los objetivos de iPhone excepto en el dispositivo. Aunque le daré una oportunidad. –

1

Mientras que las herramientas de Apple han mejorado con el tiempo, todavía dejan mucho que desear. GHUnit es mucho mejor, tiene un corredor de prueba real, y hace que sea muy fácil establecer puntos de interrupción, etc. Incluso puede aprovechar todos sus SenTests existentes.

Get it on github.

Pueden crearse instancias de todo el código UIKit sin preocupaciones. Lo uso para probar UIViewControllers, afirmar puntos de venta y hacer pruebas de comportamiento.

Cuestiones relacionadas