2011-11-01 9 views
15

He estado leyendo mucho sobre el desarrollo basado en pruebas y he decidido que quiero probarlo en un proyecto pequeño. Como referencia, actualmente estoy leyendo 'Crecimiento de software orientado a objetos, guiado por pruebas'.¿Cómo puedo crear pruebas de extremo a extremo para aplicaciones Mac (Cocoa)?

Entiendo cómo probar mi unidad unitariamente y cómo probar algunas partes de la UI, pero estoy luchando para establecer pruebas completas. Por ejemplo, probar que una determinada ruta a través de toda mi aplicación produce el resultado correcto (esta es mi comprensión básica de una prueba de extremo a extremo).

No es necesario simular eventos de clic, pero es necesario tener algún tipo de conexión a la interfaz de usuario.

¿Estoy en lo cierto al pensar que necesito una combinación de pruebas "lógicas" (prueba sin iniciar la aplicación), pruebas de "aplicación" (prueba con el lanzamiento de la aplicación) y la funcionalidad asíncrona de algo así como GHUnit para lograr esto?

EDIT:

Después de leer algunas de las respuestas a continuación, suena como que estoy en busca de pruebas de funcionamiento de extremo a extremo, pero creo que debería dar un ejemplo de una prueba como me lo imagino.

  1. Inicie la aplicación.
  2. Llamar a la función de inicio de sesión con una prueba de credenciales de los usuarios. (Nota: no necesariamente necesita automatización de UI).
  3. Verifique que una etiqueta en la ventana diga "Iniciar sesión ...".
  4. Después de verificar con éxito al usuario, verifique que la etiqueta ahora diga "¡Bienvenido, Adam!".

KIF parece que podría funcionar, ya que tiene pasos para verificar los cambios en los elementos de la interfaz de usuario y parece que también hay una rama de Mac OSX. Estoy seguro de que también podría escribir una pequeña clase que constantemente sondee la IU para ver los cambios que espero y se agote después de cierto tiempo, pero me pregunto si esta es la forma correcta de hacerlo.

Sin embargo, tal vez estoy tratando de tomar lo que estoy leyendo en 'Growing Object-Oriented Software, Guided by Tests' y tratar de aplicarlo literalmente a Cocoa.

Otra actualización:

Así que he estado leyendo el consejo hasta el momento, comprueba los diversos lugares vinculados y comenzó a poner en práctica algo mientras sigue haciendo referencia al libro. Creo que lo que realmente estoy tratando de obtener es el Test-Driven -parte de desarrollo. Lo que más resaltó en dicho libro fue que describieron primero lo que querían que ocurriera desde la perspectiva de los usuarios con las pruebas de aceptación.

Me doy cuenta de que las pruebas sólidas de la unidad serán necesarias tan pronto como empiece a escribir métodos, pero antes quise escribir algunas pruebas de aceptación de alto nivel, usando parte de la IU. Empecé a escribir mi propia clase de "controlador" de aplicaciones, utilizando algunos métodos similares a las ideas de GHAsyncTestCase para ayudarme a lograr esto. ¿Esto suena correcto/útil/necesario?

Realmente aprecio todos los comentarios hasta ahora y definitivamente me han ayudado a resolver por mi cuenta lo que estoy tratando de hacer y las diversas áreas de prueba que existen. Terminaré pronto esta pregunta, ya que cada vez es más grande, ¡así que cualquier consejo final es bienvenido!

+1

Gran primera pregunta! – logancautrell

Respuesta

3

Creo que lo fundamental que obtuve de "Growing software orientado a objetos" era para desacoplar tanto como sea posible de la interfaz de usuario. Sin código para mirar es más difícil dar sugerencias pero con su revisión, creo que separar el bit de "verificar una etiqueta dice ..." de la interfaz de usuario. ¿Qué está configurando este mensaje? ¿Puedes probarlo?

Cuanto más se puede desacoplarse de la interfaz de usuario Cuanto más se pueda unidad de prueba (más rápido y fácil) en lugar de integrar otros marcos o controladores de elementos de interfaz de usuario.

+0

Mientras yo también tuve este mensaje-de acoplamiento, sus pocas pruebas principales "end-to-end" tenía cosas tales como "revise la etiqueta dice esto después de realizar esta acción". ¿Estoy demasiado colgado en esto? Pero sí, tal vez debería trabajar más en el desacoplamiento de la interfaz de usuario. Después – Adam

+0

simplemente comenzar a escribir pruebas y comenzar el desarrollo guiado por pruebas, me di cuenta de que la necesidad de probar realmente la interfaz de usuario se limita a unos pocos casos raros y la mayoría de las veces se puede evitar esto mediante la disociación de la interfaz de usuario y el uso de burla. Si bien todas las respuestas en este hilo me ayudaron a comprender, el tuyo fue el más cercano a lo que finalmente descubrí. – Adam

0

Creo que puede utilizar las funciones de accesibilidad para crear un script de la IU.Verificaría los videos de WWDC 2011 para uno titulado "Patrones de diseño para simplificar la accesibilidad de Mac". Hicieron algo similar en 2010.

+0

Mientras que las funciones de vídeo y la accesibilidad son útiles, no es cubrir la experiencia completa de extremo a extremo que estoy tratando de entender más acerca de, en relación con el cacao y Xcode. También afirmé que la simulación de la interacción del usuario no es realmente necesaria para las pruebas de extremo a extremo (como yo lo entiendo). – Adam

0

Según su respuesta al @Norman, supongo que está buscando recomendaciones que abarquen tanto el extremo a extremo funcional como el extremo a extremo basado en la interfaz de usuario, pero quizás una interfaz de usuario El marco de automatización puede cambiar tu mente? Algo intrusiva como FoneMonkey podría ser útil: http://www.gorillalogic.com/fonemonkey

Si eso no funciona para usted, estaría interesado en saber por qué lo & "brecha" se percibe en estos ensayos conducidos interfaz de usuario frente a las pruebas funcionales basados ​​en código?

+0

Gracias, creo que incluso podría estar un poco confundido acerca del "vacío" que mencionaste también, así que he intentado mejorar mi pregunta. FoneMoney se parece a KIF, aunque no vi una mención en una versión de Mac. – Adam

1

Usted puede estar interesado en el marco KIF de la plaza: http://corner.squareup.com/2011/07/ios-integration-testing.html

se ve muy fresco para las pruebas de integración/interfaz de usuario.

+0

Gracias, eso se ve muy interesante y también parece que hay una rama específicamente para Mac OSX. Por las dudas, he agregado un poco de aclaración a mi pregunta. – Adam

Cuestiones relacionadas