2011-09-05 11 views
6

Estoy tratando de configurar una integración continua con un proyecto de Android y Cucumber.¿Cómo hacer las pruebas de integración de Android Cucumber?

La idea es escribir pruebas en Cucumber y ejecutar las pruebas en mi compilación de Android a través de Cuke4Duke y NativeDriver para Android.

Cuando lo tengo en ejecución, planeo usar Maven y un servidor Jenkins para automatizar las pruebas, por lo que se ejecuta cada vez que me comprometo con el repositorio de Subversion.

¿Ha hecho esto antes? ¿Hay alguna buena guía en alguna parte? ¿O es una mala idea hacerlo de esta manera?

+0

Te recomiendo que pruebes esta biblioteca: https://github.com/mauriciotogneri/green-coffee Solo tienes que importarla y luego podrás ejecutar tus pruebas escritas en Gherkin. –

Respuesta

0

No creo que lo que ha planeado sea una mala idea. Pero no conozco a nadie que haga Android CI con esa configuración en particular.

Quizás desee echar un vistazo a Robotium, es como Selenium para Android y ofrece una DSL muy rica que ayudará con sus implementaciones de paso cuke4duke.

0

En mi empresa utilizamos una configuración un poco diferente (pero probablemente tendrás que resolver desafíos similares): Jenkins + Jenkins Android Plugin + Robotium + Ant. Descubrimos que la hormiga es difícil de mantener cuando intentas usarla para algo más complicado que la compilación simple y estamos reescribiendo nuestros guiones para gradle.

Funciona bastante bien, sin embargo, debe tener en cuenta dos posibles problemas: 1. el emulador es lento (incluso en servidores rápidos): puede considerar conectar un dispositivo físico a su servidor. 2. es probable que tengas que configurar el bloqueo (o usar solo un ejecutor) para el emulador, ya que el uso de múltiples instancias del emulador es difícil/complicado.

0

Lo que hemos hecho es escribir un motor de instrumentación de prueba sobre Robotium. Este motor es principalmente una máquina de estado que lee palabras clave de un archivo de texto y las convierte en llamadas API de Robotium. Inicialmente notamos que las entradas y salidas eran las mismas: pulsaciones de usuario en la pantalla, se visualiza una nueva pantalla o se muestra un texto nuevo.

Eso nos permite implementar la prueba de palabra clave pero se ejecuta en el dispositivo de forma no remota.

Es un 20% de esfuerzo obtener el 80% del beneficio: fácil de escribir/agregar nuevas pruebas que sean legibles por cualquiera. Por supuesto, hay limitaciones, pero nuestro objetivo se logró.

Saludos Ch

Cuestiones relacionadas