ios - source - Buscando un esquema decente para implementar el entorno de pruebas de aceptación utilizando tecnologías nativas de Objective-C y Mac
herramientas de testing para aplicaciones web (1)
Fondo
Estoy buscando una forma de implementar un esquema similar al que utiliza la biblioteca Frank para implementar "Pruebas de aceptación automatizadas para aplicaciones iOS nativas", pero quiero que este esquema se base en las tecnologías nativas iOS / MacOSX. Perdón por el siguiente TLDR pero merece una explicación detallada.
1. Aquí hay una breve descripción de cómo funciona Frank:
tiene partes de Cliente y Servidor.
La parte del servidor está incrustada en una aplicación con la que queremos ejecutar pruebas de aceptación. Los tutoriales de Frank nos muestran cómo crear un objetivo duplicado del objetivo principal de una aplicación e incrustarle un servidor HTTP Frank.
Parte cliente: es principalmente un Pepino que ejecuta escenarios de texto plano: cada escenario contiene directivas que deben ejecutarse contra una aplicación (campo de texto de relleno, botón táctil, asegúrese de que exista un elemento específico en una página, etc.). Además, cada escenario lanza su propia instancia de aplicación de esta manera proporcionando un estado nuevo cada vez que ingresamos a un nuevo escenario.
El cliente (puente de Cucumber y Ruby-to-Objective-C) se comunica con el servidor (servidor HTTP incrustado en una aplicación) a través del protocolo HTTP. Utiliza convenciones especiales para que el cliente pueda decirle al servidor qué debe hacer una aplicación para que se pueda realizar el escenario específico.
2. Recientemente encontré el siguiente artículo escrito por el autor de Frank Pete Hodgson:
http://blog.thepete.net/blog/2012/11/18/writing-ios-acceptance-tests-using-kiwi/
En el cual sugiere una manera más simple de escribir pruebas de aceptación para los desarrolladores que no les gusta confiar en herramientas externas como Cucumber y Ruby. Permítanme citar al autor mismo:
Antes de comenzar, permítanme aclarar que personalmente no utilizaría este enfoque para escribir pruebas de aceptación. Prefiero usar un lenguaje de nivel superior como Ruby para escribir este tipo de pruebas. El código de prueba es mucho menos laborioso y mucho más expresivo, suponiendo que te sientas cómodo con el rubí. Y es por eso que quería probar este experimento. A lo largo del tiempo he hablado con bastantes desarrolladores de iOS que no se sienten cómodos escribiendo pruebas en ruby. Se sienten más cómodos en Objective-C que cualquier otra cosa, y les gustaría escribir sus pruebas en el mismo idioma que usan para su código de producción. Lo suficientemente justo.
Esta publicación de blog me inspiró a pasar rápidamente mi propia herramienta, muy cruda y primitiva, que hace exactamente lo que Pete describió en su publicación de blog: NativeAutomation .
De hecho, como describió Pete, es posible ejecutar pruebas de aceptación utilizando solo la configuración de Kiwi / PublicAutomation colocada en un objetivo simple OCTests. Realmente me gustó porque:
- Es solo puro C / Objective-C. Fue muy fácil construir un grupo inicial de ayudantes C, que se parecen a los ayudantes de Capybara :
tapButtonWithTitle, fillTextFieldWithPlaceholder, hasLabelWithTitle y así sucesivamente ...
No requiere herramientas ni idiomas externos: no es necesario en Cucumber / Ruby o cualquier otra cosa. NativeAutomation usa solo PublicAutomation que Frank también usa. PublicAutomation es necesaria para simular las interacciones del usuario en la pantalla de una aplicación: toques, rellenos, gestos ...
Es muy útil ejecutar estas pruebas directamente desde Xcode simplemente ejecutando un paquete de Pruebas unitarias de cacao. (Aunque las compilaciones de línea de comandos también son fáciles).
Problema
El problema del enfoque Kiwi/PublicAutomation es que todo el conjunto de pruebas está integrado en el paquete de la aplicación. Significa que después de ejecutar cada escenario, no es posible restablecer la aplicación para forzarla a estar en estado fresco antes de que comience la ejecución del siguiente escenario. La única forma de solucionar este problema es escribir Kiwi''s beforeEach hook con un método que realiza un restablecimiento suave de una aplicación como:
+ (void)resetApplication {
[Session invalidateSession];
[LocationManager resetInstance];
[((NavigationController *)[UIApplication sharedApplication].delegate.window.rootViewController) popToRootViewControllerAnimated:NO];
[OHHTTPStubs removeAllStubs];
cleanDatabase();
shouldEventuallyBeTrue(^BOOL{
return FirstScreen.isCurrentScreen;
});
pero en el caso de una aplicación que involucra trabajo en red, trabajos asincrónicos, datos centrales, operaciones de archivos, se vuelve difícil realizar un desmontaje real de un material que dejó el escenario anterior.
Pregunta
El problema descrito anteriormente me hizo pensar si es posible implementar un enfoque más complejo similar al enfoque de Frank, con una segunda aplicación que funciona aparte del paquete de la aplicación principal y no depende de herramientas externas como Cucumber (Ruby).
Así es como veo la forma en que podría hacerse.
Además de una aplicación principal (MainApp), hay una segunda aplicación iOS (o Mac OS X) (AcceptanceTestsRunnerApp) que contiene todo el conjunto de pruebas de aceptación y ejecuta este conjunto de aplicaciones contra un paquete principal de aplicaciones:
Arranca una nueva instancia de simulador antes de ingresar a cada nuevo escenario y ejecuta el escenario actual contra la instancia de la aplicación del simulador actual.
La pregunta es:
No estoy bien informado sobre las tecnologías Mac OSX o iOS que me permitirían hacer eso: no sé si es posible configurar una aplicación Mac OS X / iOS (AcceptanceTestsRunnerApp) que pueda tomar el control de una aplicación principal (MainApp) y ejecutar escenarios de pruebas de aceptación en su contra.
Estaré agradecido por cualquier pensamiento / sugerencia que pueda tener la gente que se sienta más cómoda con la herramienta nativa Objective-C para escribir pruebas de aceptación para aplicaciones iOS.
ACTUALIZADO MÁS TARDE
... Leí algo de documentación sobre los servicios de XPC, pero la ironía es que el esquema que estoy buscando debería ser completamente opuesto al esquema que sugiere la documentación de XPC:
Lo ideal es que mi AcceptanceTestsRunnerApp domine sobre MainApp: ejecútelo y controléelo (interacciones del usuario, aserciones sobre la jerarquía de vistas) a través de proxy de objetos al delegado de la aplicación MainApp mientras que la configuración de los servicios XPC supondría que el servicio XPC (AcceptanceTestsRunnerApp) estaría subordinado a una aplicación (MainApp ) y requerirá el servicio XPC para vivir dentro del paquete de la aplicación que quiero evitar por todos los medios.
... Mi lectura actual es Temas de programación de Objetos distribuidos . Me parece que voy a encontrar mi respuesta allí. Si nadie me proporciona guías o instrucciones, publicaré una respuesta sobre mis propias investigaciones y pensamientos.
... Este es el siguiente paso en mi misión: Objetos distribuidos en iOS .