¿Cómo puedo realizar mis pruebas independientes de Robotium UI en paralelo?

Actualización : He añadido otra respuesta que creo que da una configuración más limpia y concisa Jenkins, y se basa más directamente en Spoon.

Acabo de descubrir el complemento Jenkins MultiJob que le permite ejecutar varios trabajos en paralelo dentro de una fase.

A continuación se muestra mi trabajo, pero ligeramente frágil enfoque para hacer esto con el plugin Fork . Utilizo expresiones regulares manualmente configuradas para particionar las pruebas (ésta era la razón principal por la que intenté utilizar Fork – apoya usar regex).

El MultiJob se ve así con múltiples trabajos descendentes en una fase:

Configuración del trabajo principal

Así es como se configura mi "Android Multi Job":

Configuración del trabajo descendente

A continuación se muestra cómo se configuran los trabajos "Android Phase N" siguientes (con diferentes expresiones regulares de android.test.classes para cada uno):

Gotas

• Fork actualmente no se ejecuta en Gradle v1.0.0, como por fork plugin cuestión # 6 .
• Si desea que una regex de Fork coincida con varios paquetes diferentes, debe separar la coma de su regex. Esto no está muy bien documentado en el proyecto Fork, pero su fuente TestClassFilter muestra cómo interpretan el regex.
• Cualquier clase de prueba abstracta debe llamarse Abstract* , de lo contrario Fork intentará ejecutarlos como pruebas, creando fallos molestos. Su TestClassScanner controla esto, y el problema # 5 cambia esto.
• IIRC, debe tener instalado el complemento de huellas dactilares para que funcione la opción "Agregue los resultados de prueba descendentes". Si no lo tiene instalado, verá este error: "Las huellas dactilares no están habilitadas en esta generación. La agregación de pruebas requiere huellas dactilares".

Limitaciones

• Los resultados de las pruebas se agregan, pero sólo con los informes de prueba de JUnit XML. Esto significa que debe hacer clic en cada trabajo descendente para ver buenos resultados HTML.
• La partición manual de las pruebas basadas en expresiones regulares puede ser tediosa y propensa a errores. Si usas este enfoque, te recomiendo que tengas un trabajo semanal / semanal Jenkins para ejecutar tu suite completa de pruebas en un solo lugar, para asegurarte de que no pierdas accidentalmente ninguna prueba.
• Este enfoque Multijob requiere que configure manualmente cada trabajo descendente, uno para cada nodo esclavo que desee utilizar. Hemos elaborado un prototipo de un mejor enfoque utilizando un trabajo de Matrix, en el que sólo hay que configurar todo en un único trabajo de Jenkins). Intentaremos escribir eso en las próximas dos semanas.

Futuros

También hemos prototipado una forma de extender Spoon (la salida es más bonita que Fork ) para dividir automáticamente toda la suite de pruebas en N trabajos descendentes. Todavía necesitamos mejorarlo para agrupar todos esos resultados en una sola página HTML en el trabajo de upstream, pero desafortunadamente un error en el complemento Jenkins "Copy To Slave" está bloqueando esto de trabajar en este momento.

Puede realizar esto en 3 pasos:

1. Cree 2 nodos apuntando a la máquina de destino único (que satisface su condición para ejecutar pruebas en la misma máquina).
2. En el trabajo durante la ejecución, utilice la variable de env Jenkins $ NODE_NAME y asigne un conjunto diferente de pruebas a cada nodo (puede necesitar el complemento de parámetros de NodeLabel ).
3. Después de la ejecución tendrá 2 archivos de informe, por suerte en la misma máquina. Puede fusionarlos en uno si son archivos de texto o crear xml algo similar al formato de complemento PerfPublisher que le proporciona un informe detallado.

Esto significa que puede ejecutar 2 conjuntos de pruebas en la misma máquina (2 nodos apuntando a ella) usando un solo trabajo. La obtención de un solo informe sería complicado, pero si puedo conocer el formato que puedo ayudar.

Espero que esto sea útil

Esta respuesta es una mejora en mi respuesta MultiJob anterior .

La mejor manera que he encontrado para hacer esto es usar un trabajo de Jenkins Matrix (también conocido como "proyecto de configuración múltiple"). Esto es muy conveniente porque puedes configurar todo en un solo trabajo de Jenkins.

Spoon ahora soporta una opción --e que le permite pasar argumentos directamente al corredor de instrumentación. He actualizado su archivo README con una sección sobre Test Sharding .

Ese README debe darle lo que usted necesita, pero aquí están otros aspectos destacados de nuestra configuración de trabajo de Jenkins, en caso de que ayuda.

El User-defined Axis establece el número de nodos esclavos que queremos ejecutar. Tenemos que establecer la etiqueta en android para que nuestro proveedor de nube pueda lanzar un esclavo apropiado.

Tenemos un script run-build.sh que invoca Spoon con los parámetros correctos. Necesitamos pasar el recuento de nodos total (en este caso 6 ), y el índice del nodo esclavo específico que se está ejecutando (automáticamente presente en la variable node_index ).

Los pasos de construcción posterior no deben ser diferentes a los existentes. En el futuro probablemente tendremos que añadir algo para recoger los resultados en el nodo maestro (esto ha sido sorprendentemente difícil de entender). Por ahora, puedes hacer clic en los resultados de los esclavos.

Puede utilizar, por ejemplo, Jenkins MultiJob Plugin y Testdroid API para enviar sus APK a dispositivos reales. Esa es probablemente la manera más fácil de hacerlo. Ref aquí .