Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Testing
Code

Introducción a las pruebas de iOS con la automatización de la interfaz de usuario

by
Difficulty:IntermediateLength:LongLanguages:

Spanish (Español) translation by Elías Nicolás (you can also view the original English article)

Solo imagine poder escribir scripts que interactúen automáticamente con su aplicación iOS y poder verificar los resultados. Con UI Automation puedes. UI Automation es una herramienta proporcionada por Apple para realizar un mayor nivel de prueba en su aplicación iOS más allá de lo que se puede lograr con XCTest.

1. Caja blanca frente a Black Box Testing

Es posible que haya escuchado la comparación de las pruebas de caja blanca frente a las pruebas de caja negra con respecto a cómo se podría probar una pieza de software. Si no está familiarizado con estos conceptos, permítame explicar cómo funcionan.

Pruebas en White Box

Imagina que hay una pieza de software ejecutándose dentro de una caja. Con las pruebas de caja blanca, puede ver dentro de la caja y ver todas las piezas de cómo funciona el software, y luego tomar decisiones informadas sobre cómo probar el software. También puede tener ganchos de nivel más profundo en el software de las pruebas que escribes.

La prueba unitaria es prueba de caja blanca. Al escribir pruebas unitarias, el probador tiene acceso detallado al código bajo prueba. El verificador realmente puede escribir pruebas que aprovechan el software bajo prueba en el método, o unidad, nivel.

En el desarrollo de software de iOS, utilizamos el marco XCTest para realizar este tipo de pruebas. Eche un vistazo a otro tutorial que escribí sobre cómo comenzar con XCTest.

Prueba en Black Box

En las pruebas de caja negra, la caja es opaca. El probador no puede ver dentro de la caja. El probador no puede acceder y no sabe sobre la implementación del código base para escribir pruebas. En cambio, el probador se ve obligado a utilizar la aplicación como lo haría un usuario final interactuando con la aplicación y esperando su respuesta, verificando los resultados.

Hay al menos dos formas de ejecutar este tipo de prueba.

  • Un probador que realiza de manera repetida y manual una serie de pasos predefinidos y verifica visualmente los resultados.
  • Utilice herramientas especializadas para probar la aplicación con API que se comportan de forma similar a cómo interactúa un ser humano.

En el desarrollo de aplicaciones iOS, Apple proporciona una herramienta llamada UI Automation para realizar pruebas en black box.

2. ¿Qué es la UI Automation?

UI Automation es una herramienta que Apple proporciona y mantiene para pruebas automatizadas de nivel superior de aplicaciones iOS. Las pruebas están escritas en JavaScript, adhiriéndose a una API definida por Apple.

Las pruebas de escritura pueden simplificarse al confiar en las etiquetas de accesibilidad para los elementos de la interfaz de usuario en su aplicación. No se preocupe, si no tiene estos definidos, hay alternativas disponibles.

La API de automatización de UI carece del formato típico basado en xUnit para escribir pruebas. Una diferencia con las pruebas unitarias es que el probador debe registrar manualmente el éxito y las fallas. Las pruebas de UI Automation se ejecutan desde el instrumento Automation dentro de la herramienta Instruments que viene con las herramientas de desarrollador de Apple. Las pruebas se pueden ejecutar en el simulador de iOS o en un dispositivo físico.

3. Escribir pruebas UI Automation

Paso 1: abra el proyecto de ejemplo

He actualizado el proyecto de ejemplo utilizado en el tutorial anterior sobre pruebas de iOS con algunos elementos adicionales de la interfaz de usuario que proporcionan algunos ganchos útiles para agregar pruebas UI Automation. Descarga el proyecto de GitHub. Abra el proyecto y ejecute la aplicación para asegurarse de que todo esté funcionando como se esperaba. Debería ver una interfaz de usuario similar a la que se muestra a continuación.

Sample Application screenshot

Antes de escribir cualquier prueba, siéntase libre de probar la aplicación de muestra para familiarizarse con su funcionalidad. Como usuario, puede ingresar texto en el campo de texto y presionar el botón para ver una etiqueta en la pantalla que muestra la cadena invertida ingresada.

Paso 2: crea una prueba UI Automation

Ahora que está familiarizado con la aplicación de muestra, es hora de agregar una prueba UI Automation. UI Automation es una herramienta que se puede encontrar en Instruments. Para ejecutar la aplicación de muestra en Instrumentos, seleccione Product > Profile en el menú de Xcode. Seleccione Automation de la lista de herramientas.

Instrument chooser screenshot

La ventana principal de instrumentos se abrirá con un solo instrumento listo para ejecutarse, el instrumento de automatización (el instrumento Automation ejecuta casos de prueba UI Automation). También verá un área en la mitad inferior de la ventana que se parece a un editor de texto. Este es el editor de script. Aquí es donde escribirás tus pruebas UI Automation. Para esta primera prueba, siga las instrucciones a continuación, agregando cada línea al script en el editor de script.

Comience almacenando una referencia al campo de texto en una variable.

Establezca el valor del campo de texto.

Verifique que el valor se estableció correctamente y, si lo fue, pase la prueba. Fallar la prueba si no fue así.

Si bien esta prueba es bastante trivial, sí tiene valor. Acabamos de escribir una prueba que prueba la presencia de un campo de texto cuando se lanza la aplicación y que prueba si se puede establecer una cadena aleatoria como el valor del campo de texto. Si no me crees, elimina el campo de texto del storyboard y ejecuta la prueba. Verás que falla.

Esta prueba demuestra tres piezas importantes de escritura de pruebas de automatización de la interfaz de usuario. Primero, le muestra cómo acceder a un elemento de interfaz de usuario simple, el campo de texto. Específicamente, accedemos a un diccionario de todos los campos de texto en la vista base de la aplicación a través de target.frontMostApp().mainWindow().textFields() y luego buscamos el campo de texto que nos interesa al buscar el que tiene la clave Input Field. Esta clave es en realidad la etiqueta de accesibilidad del campo de texto. En este caso, está definido en el guión gráfico. También podemos establecer la etiqueta de accesibilidad en código usando la propiedad accessibilityLabel en NSObject.

El acceso a la ventana principal de la aplicación, la aplicación más frontal y el objetivo son comunes cuando se trabaja con la automatización de la interfaz de usuario. Le mostraré cómo hacer esto más fácil y menos detallado más adelante en este tutorial.

En segundo lugar, esto le muestra que puede interactuar con los elementos de la interfaz de usuario en la pantalla. En este caso, establecemos el valor del campo de texto, imitando al usuario que interactúa con la aplicación al ingresar texto en el campo de texto.

Y tercero, el ejemplo también muestra una técnica para verificar lo que sucede en la aplicación. Si el valor se establece con éxito, la prueba pasa. Si el valor no está establecido, la prueba falla.

Paso 3: Guardar las pruebas

Si bien escribir pruebas en el editor de scripts es conveniente, rápidamente se vuelve engorroso y difícil de mantener. Si abandona Instrumentos, cualquier cambio no guardado se descarta. Necesitamos guardar las pruebas que escribimos. Simplemente copie y pegue su prueba en un documento nuevo en su editor de texto favorito y guárdelo. Puede encontrar las pruebas creadas en este tutorial en el proyecto de ejemplo en Jumblify/JumblifyTests/AutomationTests.js.

Para ejecutar la prueba, seleccione la pestaña del medio en el panel de la derecha, al lado del editor de scripts, y seleccione Add > Import.

Instruments screenshot

Se le pedirá que seleccione la secuencia de comandos para importar. Navegue al script guardado e impórtelo. Todavía puede cambiar la secuencia de comandos en el editor de secuencia de comandos. Cualquier cambio se guardará automáticamente en el archivo externo que haya creado.

Paso 4: tocando un botón

Actualicemos nuestra prueba para probar la interacción con el botón. Nuestra prueba ya agrega texto al campo de texto, por lo que solo necesitamos agregar código para tocar el botón. Consideremos primero cómo encontrar el botón en la vista para que se pueda tocar. Hay al menos tres formas de lograr esto y cada enfoque tiene sus compensaciones.

Enfoque 1

Podemos programar mediante programación una coordenada (X, Y) en la pantalla. Hacemos esto con la siguiente línea de código:

Por supuesto, no tengo idea si esas son incluso las coordenadas del botón en la pantalla y no voy a preocuparme por eso, porque este enfoque no es la herramienta adecuada para este trabajo. Solo lo menciono para que sepas que existe. Usar el método Tap en target para tocar un botón es propenso a errores, porque ese botón no siempre se encuentra en esa coordenada específica.

Enfoque 2

También es posible encontrar el botón buscando en la matriz de botones de la ventana principal, de forma similar a cómo accedimos al campo de texto en la primera prueba. En lugar de acceder al botón directamente usando una tecla, podemos recuperar una matriz de botones en la ventana principal y codificar un índice de matriz para obtener una referencia al botón.

Este enfoque es un poco mejor. No estamos codificando una coordenada, pero estamos codificando un índice de matriz para encontrar el botón. Si agregamos otro botón en la página, puede romper accidentalmente esta prueba.

Enfoque 3

Esto me lleva a la tercera forma de encontrar el botón en la página, usando etiquetas de accesibilidad. Mediante el uso de una etiqueta de accesibilidad, podemos acceder directamente al botón, simplemente nos gustó encontrar un objeto en un diccionario con una tecla.

Sin embargo, si agrega la línea anterior al script y lo ejecuta, obtendrá un error.

Instruments Error Message Screenshot

Esto se debe a que aún no hemos definido la etiqueta de accesibilidad para el botón. Para hacerlo, vaya a Xcode y abra el storyboard del proyecto. Busque el botón en la vista y abra el Identity Inspector a la derecha (View > Utilities > Identity Inspector). Asegúrese de que Accessibility esté habilitado y configure Label para el botón Jumblify Button.

Interface Builder Accessibility Inspector Screenshot

Para ejecutar la prueba nuevamente, deberá ejecutar la aplicación desde Xcode seleccionando Product > Run y luego perfilar la aplicación nuevamente seleccionando Product > Profile. Esto ejecuta las pruebas y cada prueba debe pasar ahora.

Paso 5: Verificar Jumbled String (cadena desordenada)

Como mencioné anteriormente, nuestra aplicación toma una cadena de texto como entrada y, cuando el usuario toca el botón, muestra la cadena invertida. Necesitamos agregar una prueba más para verificar que la cadena de entrada se haya invertido correctamente. Para verificar que el UILabel esté lleno con la cadena correcta, necesitamos averiguar cómo hacer referencia a UILabel y verificar la cadena que muestra. Este es un problema común al escribir pruebas de automatización, es decir, averiguar cómo hacer referencia a un elemento en la aplicación para hacer una afirmación sobre él.

Hay un método en casi todos los objetos en la API de automatización de la interfaz de usuario, logElementTree. Este método registra los elementos anidados de un elemento dado. Esto es muy útil para comprender la jerarquía de elementos en la aplicación y ayuda a determinar cómo orientar un elemento específico.

Veamos cómo funciona esto registrando el árbol de elementos de la ventana principal. Eche un vistazo a la siguiente línea de código.

Agregar esta línea al script de prueba da como resultado el siguiente resultado:

Instruments logElementTree screenshot

Como puede ver, hay un subelemento UIAStaticText de la UIAWindow y también puede ver que tiene un nombre de ih, que también es la cadena invertida que necesitamos verificar. Ahora, para completar nuestra prueba, solo necesitamos agregar código para acceder a este elemento y verificar que esté presente.

¿Por qué solo necesitamos verificar si el elemento UIAStaticText está presente? Como el nombre del elemento es la cadena invertida de la cadena de entrada, verificar su presencia confirma que la secuencia se invirtió correctamente. Si el elemento no existe cuando se hace referencia por nombre, la cadena invertida, significa que la cadena no se invirtió correctamente.

4. Raspando la superficie

Hay muchas otras maneras en que un usuario final puede interactuar con un dispositivo iOS mientras usa su aplicación. Esto significa que hay muchas otras maneras en que puede usar la UI Automation de usuario para simular estas interacciones. En lugar de intentar capturar una lista completa de estas interacciones, lo dirigiré a la documentación de referencia de UI Automation.

Para cada tipo de objeto con el que puede interactuar, puede ver la lista de métodos disponibles en ese objeto. Algunos métodos son para recuperar atributos sobre el objeto, mientras que otros son para simular la interacción táctil, como flickInsideWithOptions en UIAWindow.

Grabando una sesión

A medida que intentes probar más y más aplicaciones complicadas con UI Automation, verás que a veces es bastante tedioso usar repetidamente logElementTree para encontrar el elemento que estás buscando. Esto también se vuelve tedioso y complejo para aplicaciones con una jerarquía de vista compleja o navegación. En estos casos, puede usar otra función de Instruments para registrar un conjunto de interacciones del usuario. Lo que es aún más genial es que Instruments genera el código de JavaScript de automatización de la interfaz de usuario que se necesita para reproducir las interacciones registradas. Así es como puedes probarlo por ti mismo.

En Instrumentos y con el instrumento de Automatización seleccionado, busque el botón de grabación en la parte inferior de la ventana.

Instruments screenshot showing record button

Si hace clic en el botón de grabación, Instruments comenzará una sesión de grabación como se muestra en la siguiente captura de pantalla.

Instruments Screenshot showing capture in progress

Instruments lanzará su aplicación en el simulador de iOS y podrá interactuar con ella. Los instrumentos generarán un script basado en sus interacciones en tiempo real. Darle una oportunidad. Gire el simulador de iOS, toque ubicaciones aleatorias, realice un gesto de deslizamiento, etc. Es una forma realmente útil de ayudar a explorar las posibilidades de UI Automation.

Evite el código monolítico

Como probablemente pueda prever, si continuamos agregando más pruebas al archivo de prueba que hemos creado con el mismo método, será difícil de mantener. ¿Qué podemos hacer para evitar que eso suceda? En mis pruebas, hago dos cosas para resolver este problema:

  • Una prueba para una función: esto implica que las pruebas que escribimos deben centrarse en una pieza específica de funcionalidad. Incluso le daré un nombre apropiado, como testEmptyInputField.
  • Agrupe las pruebas relacionadas en un archivo: también agrupo pruebas relacionadas en el mismo archivo. Esto mantiene el código en un archivo manejable. Esto también hace que sea más fácil probar las piezas de funcionalidad por separado mediante la ejecución de las pruebas en un archivo específico. Además, puede crear un script maestro en el que llame a las funciones o pruebas que ha agrupado en otros archivos de prueba.

En el siguiente fragmento de código, importamos un archivo JavaScript y esto hace que las funciones en ese archivo JavaScript estén disponibles para nosotros.

Conclusión

En este tutorial, ha aprendido el valor de las pruebas de nivel superior y cómo la Automatización de UI puede ayudar a llenar ese vacío. Es otra herramienta en su caja de herramientas para ayudar a garantizar que envíe aplicaciones confiables y robustas.

Referencias

Referencia JavaScript Automation IU

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.