Pruebas de interfaz de usuario de Android e iOS con Calabash

La prueba es una parte esencial de cualquier proceso de desarrollo de aplicaciones móviles. Ya sea que esté automatizando tales pruebas o no, ningún desarrollador en su sano juicio considera que su trabajo está hecho a menos que haya probado su aplicación.

Una aplicación bien probada generalmente pasa por varios pasos de prueba: prueba unitaria, prueba de integración, prueba de aceptación, etc. A medida que crece su aplicación, aumenta la importancia de las pruebas y la automatización en las pruebas se convierte en una necesidad.

Mientras que otras plataformas, como la web, han avanzado significativamente en términos de marcos y mecanismos de prueba, el ámbito móvil no se queda atrás. En este artículo, aprenderá cómo puede usar Calabash para automatizar la interfaz de usuario de sus aplicaciones de Android e iOS usando instrucciones sencillas en inglés y hacer que las pruebas de aceptación sean lo menos dolorosas posible.

¿De qué se tratan las pruebas de interfaz de usuario?

Si ha estado probando sus aplicaciones manualmente, probablemente esté perdiendo una gran parte de su tiempo realizando las mismas tareas una y otra vez. Realiza algunos cambios en el código, crea la aplicación, la ejecuta en un dispositivo o en un emulador y juega con la aplicación para averiguar si funciona como se esperaba.

Al automatizar las pruebas de IU, puede realizar esos mismos pasos manuales automáticamente. Si su aplicación tiene un tamaño decente, esto puede ahorrarle mucho tiempo y también evitar que su aplicación esté plagada de errores vergonzosos, especialmente los de regresión.

“Eso suena increíble”, dices, pero ¿cómo lo haces para tu aplicación de Android o iOS?

Marcos de pruebas de interfaz de usuario para Android e iOS

Si lee la documentación oficial para Android e iOS, le sugieren que escriba y ejecute pruebas de interfaz de usuario en sus IDE oficiales. Para Android, es Android Studio y para iOS, es Xcode.

La documentación oficial llega incluso a recomendar marcos específicos para las pruebas. La documentación oficial de Android cubre algunos temas sobre Espresso, el marco de prueba de la interfaz de usuario de Android. De manera similar, Apple sugiere usar el marco XCTest.

Y si va a trabajar seriamente en las pruebas de IU, puede seguir estas sugerencias, lo cual tiene sentido ya que Google mantiene Espresso y es parte del Repositorio de soporte de Android. Es muy probable que Espresso sea compatible con todas las funciones nuevas que Google introducirá para Android en el futuro. Podría decir lo mismo sobre el marco XCTest para iOS.

Sin embargo, vale la pena tener en cuenta que, a pesar de los numerosos beneficios de las pruebas automatizadas, muchos desarrolladores simplemente no las escriben.

Todos los desarrolladores que conocen las automatizaciones de prueba, en el fondo, saben que es una gran idea. Pero, cuando se trata de sentarse y escribir estas pruebas, muchos desarrolladores comienzan a preguntarse si vale la pena su tiempo, porque "tocar el botón" manualmente resulta ser una operación mucho más rápida que escribir un código que "toque este botón". automáticamente. A veces, los clientes y gerentes, que esperan ansiosos para probar la aplicación, tampoco ayudan.

Muchos desarrolladores, en ese momento, deciden que es mejor continuar trabajando en nuevas funciones de la aplicación en lugar de escribir pruebas de IU automatizadas para las existentes.

Cuando la aplicación crece, se vuelve cada vez más lento "tocar estos botones" manualmente cada vez que actualiza la aplicación.

Pero, ¿qué pasaría si hubiera un marco que facilitara las pruebas de IU y no le diera ninguna excusa para no escribir pruebas de IU para sus aplicaciones?

Conoce a Calabaza.

Calabash: prueba de aceptación automatizada para aplicaciones móviles

Hace aproximadamente un año, comencé a buscar un marco de prueba que fuera fácil de usar para las personas que no son desarrolladores de software. Y fue entonces cuando encontré a Calabash.

Este marco de prueba de código abierto, desarrollado y mantenido por el equipo de Xamarin, funciona tanto para Android como para iOS. Le permite escribir y ejecutar pruebas de aceptación automatizadas para aplicaciones móviles.

Las pruebas de aceptación son generalmente lo que viene después de las pruebas del sistema que determinan si su aplicación cumple con los requisitos comerciales. Dado que funciona en el nivel de la interfaz de usuario, esto funciona bien como nuestra elección de marco de automatización de pruebas de interfaz de usuario.

Calabash puede interactuar con su aplicación como lo hacen Espresso o XCTest. Sin embargo, lo que hace que Calabash sea una excelente opción aquí es su compatibilidad con Cucumber.

Cucumber es una herramienta que puede ejecutar pruebas automatizadas escritas en un lenguaje sencillo (si lo desea, puede ajustarlo para usar cualquier otro lenguaje sencillo). Entonces, para escribir pruebas automatizadas en Cucumber, el probador no necesita saber Java, Objective-C o cualquier otro lenguaje de programación.

¿Qué hace que Calabash funcione?

Calabash framework consta de bibliotecas que pueden interactuar con las aplicaciones de Android e iOS. Se puede ejecutar en dispositivos reales. Entonces puede hacer cosas que el probador está haciendo manualmente.

Hay dos proyectos diferentes en GitHub que hacen posible Calabash:

• calabaza-android - para Android

• calabaza-ios - para iOS

Calabash puede funcionar con cualquier marco de prueba basado en Ruby. En este artículo, cubriremos Cucumber, la forma más popular y conveniente de escribir pruebas para Calabash.

Antes de continuar, si desea probar Calabash mientras sigue el resto del artículo, asegúrese de tener Ruby instalado en su máquina. Puede encontrar instrucciones detalladas de instalación aquí.

A continuación, instale Calabash para su plataforma favorita siguiendo los enlaces de GitHub anteriores.

Escribiendo tu primera prueba en Calabash

Escribir pruebas en Calabash es bastante fácil. Veamos cómo se ve una prueba simple para una aplicación de iOS:

 Feature: User Login Scenario: Unsuccessful user login Given the app has launched Then I wait for the "Login" button to appear When I enter "tstuser" into the "Username" field And I enter "qwerty" into the "Password" field And I touch "Login" Then I should see "Username you entered is incorrect" Scenario: Successful user login Given the app has launched Then I wait for the "Login" button to appear When I enter "testeruser" into the "Username" field And I enter "qwerty" into the "Password" field And I touch "Login" Then I should see "Hey testeruser!"

Aquí, una aplicación se está probando con un nombre de usuario y una contraseña incorrectos, y luego se está probando con un nombre de usuario y una contraseña correctos. La prueba espera que la aplicación falle al iniciar sesión en el primer escenario, pero tenga éxito en el segundo.

Puede crear tantos escenarios como necesite, y todo lo que necesita hacer es dividir los pasos/instrucciones en oraciones simples en inglés. ¡Como si escribieras una historia!

Cualquiera que sepa sobre el desarrollo impulsado por el comportamiento (BDD) ya estará familiarizado con esto.

¿Cómo funciona la calabaza?

Para ver qué sucede detrás de los pasos que usa el probador, puede abrir el proyecto en GitHub y verificar el siguiente archivo:

 calabash-cucumber/features/step_definitions/calabash_steps.rb

Veamos una definición del siguiente paso:

 When I enter "testeruser" into the "Username" field

 Then /^I enter "([^\"]*)" into the "([^\"]*)" field$/ do |text_to_type, field_name| touch("textField marked: '#{field_name}'") wait_for_keyboard keyboard_enter_text text_to_type sleep(STEP_PAUSE) end

Este pequeño fragmento de código de Ruby busca un campo específico, lo toca, espera a que aparezca el teclado, escribe el texto de la variable text_to_type y espera un poco antes de pasar al siguiente paso.

La primera palabra del paso puede ser "Dado", "Cuando", "Entonces", "Y" o "Pero". No importa qué palabra clave usarás. Puedes usar cualquiera de ellos para aclarar la historia.

Cómo agregar pasos personalizados

Si necesita un paso que aún no está implementado en Calabash, puede escribirlo usted mismo. La sintaxis es exactamente la misma que en los pasos ya predefinidos.

Por ejemplo, si un probador necesita acceder al campo de entrada por marcador de posición, en lugar del nombre del campo:

 Then /^I enter "([^\"]*)" into the field with placeholder "([^\"]*)"$/ do |text_to_type, placeholder| touch("textField placeholder:'#{placeholder}'") wait_for_keyboard() keyboard_enter_text text_to_type sleep(STEP_PAUSE) end

La definición de este paso es muy similar a la anterior, pero está accediendo al campo por marcador de posición en lugar del nombre del campo. Dada la apariencia de su aplicación, esto puede facilitar aún más las cosas para el evaluador.

Y también es fácil para el desarrollador. El desarrollador implementa el paso una vez y luego el probador lo usa cuando lo necesita. Además, no necesita saber mucho de Ruby para implementar sus propios pasos personalizados.

Puede encontrar las funciones de Ruby que puede usar, aquí:

http://www.rubydoc.info/gems/calabash-cucumber/Calabash/Cucumber

Nube de prueba de Xamarin

Hay un desafío más cuando se prueban aplicaciones móviles. Debe probarlos en tantos dispositivos como sea posible, porque hay tantos dispositivos y tantas versiones del sistema operativo.

Aquí es donde Xamarin Test Cloud ayuda mucho. Hay alrededor de 2000 dispositivos reales en la nube y la buena noticia es que es compatible con las pruebas de Calabash.

Las mismas pruebas de Calabash que lo ayudaron a ahorrar tiempo al evitar que hiciera un trabajo repetitivo ahora se pueden usar para probar su aplicación en muchos dispositivos reales.

Comience a escribir pruebas de interfaz de usuario

Si Calabash es la solución de prueba que su aplicación necesita, con las ventajas que trae, no deja lugar a excusas cuando se trata de escribir pruebas de IU automatizadas para sus aplicaciones móviles. Calabash puede fallar si su aplicación depende en gran medida de ciertas características del dispositivo (por ejemplo, la cámara), pero aun así hace que las pruebas de escritura para la mayoría de las aplicaciones sean una tarea mucho más fácil.