cocoa - resueltos - johnson r 2012 págs 32 62
¿Cómo se prueban las GUI de Cocoa? (5)
Puede comprobar y considerar Berenjena por TestPlant (formalmente Redstone Software) en http://www.testplant.com/ .
Aquí hay un artículo que Apple presentó el año pasado.
Me gustaría escribir algunas pruebas para la GUI de mi programa Cocoa.
¿Hay algún buen marco de prueba GUI para las aplicaciones Cocoa? Lo único que encontré es Squish , que, a 2.400 €, está muy por encima de mi presupuesto ...
¿Algunas ideas? ¿Cómo se prueban las GUI de Cocoa?
Sugeriría que eche un vistazo a la Caja de herramientas de Google para Macintosh . Tiene, entre otras cosas buenas, un muy buen conjunto de adiciones de prueba de representación y estado para NSView y CALayers. En las pruebas de su unidad, afirma que el estado de vista / capa o la imagen renderizada coincide con una plantilla guardada (por nombre). Si la plantilla no existe en el paquete de prueba o no coincide con la versión guardada, se produce un nuevo estado codificado o TIFF renderizado para su revisión. GTM proporciona categorías para NSView y CALayer para hacer codificación y renderización de estado. Obviamente, puede anular estas categorías en sus propias subclases NSView o CALayer para codificar el estado relevante (usando el protocolo NSCoder) o la representación.
También le permite (fácilmente) enviar eventos clave de forma programática y ejecutar el bucle de ejecución desde pruebas unitarias y admite pruebas unitarias tanto en OS X como en iPhone.
El último podcast de CocoaCast tiene una entrevista con Ian Dees, autor de "Scripted GUI Testing with Ruby". Puede encontrar más información en CocoaCast
Depende de lo que quiere decir con "probar las GUI de Cocoa".
Si desea herramientas como la antigua herramienta de usuario virtual incluida con MPW, esas son pocas y distantes entre sí; estarás mirando herramientas como Squish y Berenjena.
Si desea escribir pruebas unitarias para la interfaz humana de su aplicación, le sugiero que siga un enfoque de " confianza, pero verificar " en el que confíe en que, siempre que realice las conexiones correctas (de acuerdo con su marco), su usuario pueda interactuar correctamente con su marco. Eso significa que puede hacer la mayoría de sus pruebas verificando que su modelo y código de controlador estén conectados correctamente a sus vistas.
En mi weblog, he escrito un par de ejemplos de cómo hacer esto específicamente con Cocoa, uno para probar las interfaces de usuario creadas con target-action y otro para probar las interfaces de usuario creadas con enlaces Cocoa . (Recuerde, por supuesto, que las dos tecnologías no son exclusivas: si desea arrastrar y soltar en una vista de tabla administrada mediante enlaces Cocoa, también tendría una fuente de datos y probablemente un delegado conectado a través de acción-objetivo). .)
Para lo que no escribo las pruebas unitarias, en general, es el posicionamiento o el tipo de controles en su super visión. Sin embargo, a veces eso es importante para mantenerlo correcto; en ese caso, solo puedo consultar las propiedades apropiadas de los controles y verificarlos usando las aserciones estándar.
Lo que prácticamente nunca hago es escribir código para "simular eventos". Lo más cerca que he estado de eso es construir un objeto falso de información de arrastre y pasarlo a una fuente de datos de vista de esquema para asegurarme de que manejará los arrastres correctamente.
Creé un paquete de Python de código abierto que usa la API de accesibilidad de Apple entre otros para crear una biblioteca de automatización de GUI clásica, que le da visibilidad e interacción con las GUI de Cocoa. Página de inicio de PyATOM