Pruebas automatizadas para aplicaciones móviles: Calabash for dummies (2/2). Calabash y BDD

Si utilizamos BDD (entendiendo qué es BDD), el uso de Calabash nos va a resultar de gran utilidad. Esto es así, debido a que hace uso de Gherkin el cual nos permite escribir especificaciones en un lenguaje natural y comprensible por todo el mundo, tanto negocio como desarrollo como QA.

Una vez que tengamos instalado Calabash, accediendo a la carpeta (en mi caso es la siguiente ruta C:\Ruby193\lib\ruby\gems\1.9.1\gems\calabash-android-0.5.14) podemos ver una carpeta que contiene el esqueleto de Calabash (features-skeleton).

El archivo .feature que se crea por defecto contiene lo siguiente:

La carpeta step_definitions contendrá un archivo con extensión .rb llamado “calabash_steps.rb” donde se añadirán los pasos a seguir de nuestro escenario. Además hay que añadir “require ‘calabash-android/calabash_steps’” para poder hacer uso y todos los pasos/usos que proporciona Calabash . Aquí puedes ver ejemplos de pasos que se pueden hacer o aquí.

En la carpeta support uno de los archivos que nos encontramos es “env.rb” donde se le indica a Cucumber qué librerías tiene que cargar. En este archivo hay que añadir en ese archivo la línea de código “require ‘calabash-android/cucumber’”.

A continuación os dejo un ejemplo de una feature (ya sabéis, uno o más escenarios, que corresponde más o menos a los posibles resultados de los casos de uso) y el código para pasar los casos de pruebas (step_definitions) usando Cucumber y Calabash.

Como ya he comentado, la primera imagen de arriba es un archivo .feature de Cucumber y Calabash. Un archivo .feature describe el comportamiento previsto de la aplicación. En el ejemplo tenemos una función que describe la funcionalidad de registrarse en una página.

 Cada línea después de “Scenario” corresponde a un paso. En Calabash, se puede hacer una de las siguientes cosas:

• Hacer una acción del usuario (como un toque en la pantalla, deslizar el dedo, desplazamiento, etc.),
• Hacer una afirmación (como “Then I should see details for…”)
• O tomar una captura de pantalla.

En la segunda imagen vemos el código para que pase esos casos de prueba, añadiendo en la primera línea de código “require ‘calabash-android/calabash_steps’” como decía anteriormente.

Funcionalidades como por ejemplo screen-shot hace una captura de cómo la aplicación se ve en un momento determinado durante la prueba. Las imágenes pueden ser revisadas debido a errores gráficos, algo difícil de hacer mediante afirmaciones, además comparar las capturas de cientos de dispositivos de diferentes sistemas operativos puede ser realmente útil. Este tipo de informe de pruebas visuales, es parte de lo que ofrece el Servicio LessPainful.

¿Por qué Calabash?

A día de hoy, existen muchos frameworks, para la automatización de pruebas de aceptación, como son robotium, appium… no obstante a continuación, os voy a resumir algunas ventajas de usar Calabash:

• Como ya he mencionado antes, es multiplataforma (Android e iOS)

• Se puede configurar para ejecutarse en cientos de diferentes dispositivos.
• Permite el testing sobre aplicaciones nativas, ya sabes aquellas que se programan teniendo en cuenta las particularidades de cada plataforma, e híbridas.
• Como ya he dicho, independiente del lenguaje utilizado en el desarrollo.
• Open source.

 Terminando…

A pesar de haber diferentes opciones para automatizar pruebas de aceptación para apps móviles como por ejemplo los ya mencionados appium o robotium, usar Calabash es la mejor opción para BDD, sobre todo gracias a Gherkin, ya que representa la forma en la que se escriben estas pruebas en texto plano, (igual en un futuro escribo comparando todas estas opciones). Desde luego, con todo lo que nos aporta esta buena práctica, merece la pena llevarla a cabo.

Fuente: http://www.javiergarzas.com/2015/08/pruebas-automatizadas-para-aplicaciones-moviles-calabash-for-dummies-22-calabash-y-bdd.html