Configure el lanzamiento automático de pruebas de IU de aplicaciones de Android a través de TeamCity

Tarde o temprano, cualquier probador que desarrolle la práctica de la autoevaluación enfrenta el problema de la ejecución autónoma de sus pruebas. Además, si el especialista tiene experiencia, entonces trata de lidiar con esto lo antes posible. Entonces, después de la primera prueba de autotest exitosa ejecutada localmente, decidí configurar inmediatamente el lanzamiento en TeamCity.

Observo que en nuestra empresa prácticamente no hay experiencia en el lanzamiento remoto de pruebas instrumentales de Android, por lo que tuve que buscar en Google, pero tampoco encontré ninguna guía detallada allí. Por lo tanto, decidí cortar estas instrucciones.

En la entrada tenemos:

  • Las pruebas se ejecutan con éxito localmente
  • ejecutando el servidor TeamCity
  • servidor en debian con KVM y X

El descargo de responsabilidad inmediatamente sobre el servidor donde se realizará el lanzamiento: la configuración del sistema operativo, la virtualización de hardware y el shell gráfico no es el tema de este artículo y se omitirá.

Instalar y configurar el agente de TeamCity


Comencemos con Java. Lo principal aquí es elegir la versión correcta. Tuve 3 dependencias: las pruebas en sí, las herramientas de Android y el agente de teamcity. Paré en la versión 8 para usar una JVM para todos. Si tiene menos suerte y habrá conflictos, deberá configurar el uso de varias versiones de Java en la misma máquina. Una nota más: si tiene Debian, primero debe agregar el repositorio webupd8team (google es muy rápido).

sudo apt-get install oracle-java8-installer sudo apt-get install oracle-java8-set-default 

A continuación, cree un usuario bajo el cual se iniciará el agente y, en consecuencia, todo lo demás. No olvides establecer una contraseña.

 sudo useradd -d /home/tc_agent -s /bin/bash -m tc_agent sudo passwd tc_agent 

La distribución del agente se puede realizar en la interfaz web de su teamcity. Para hacerlo, vaya a la sección Agentes y haga clic en el enlace Instalar agentes de compilación en la esquina superior derecha. Descargue y descomprima en la carpeta deseada en el servidor (recomiendo la carpeta de inicio de nuestro usuario - /home/tc_agent ). A continuación, agregue los derechos para ejecutar todos los scripts:

 sudo chmod +x /home/tc_agent/BuildAgent/bin/* 

Si su versión de teamcity admite Agent Push, entonces aún es más fácil. Simplemente abra la pestaña correspondiente en la interfaz web, haga clic en el botón Instalar agente ... y siga las instrucciones.

Configuramos una configuración. Si utilizó una instalación remota, ya se ha creado y solo necesita especificar el nombre del agente en ella. Si no, cree:

 cd /home/tc_agent/BuildAgent/conf cp buildAgent.dist.properties buildAgent.properties nano buildAgent.properties 

serverUrl= dirección de la interfaz web del servidor, y name= nombre único del agente. Si tiene varios agentes o el puerto predeterminado (9090) está ocupado, configure el suyo usando el parámetro ownPort= .

Iniciamos /home/tc_agent/BuildAgent/bin/agent.sh start comando /home/tc_agent/BuildAgent/bin/agent.sh start . Si todo está configurado correctamente, veremos a nuestro agente en la pestaña No autorizado . Autorizamos y puedes usar.

Para iniciar el agente automáticamente, cree el script /etc/init.d/teamcity_agent con el siguiente contenido:

 #!/bin/bash BINARY="/home/tc_agent/BuildAgent/bin/agent.sh" RUNAS="tc_agent" LOGFILE="/home/tc_agent/BuildAgent/logs/start.log" CMD="$BINARY $1 $2" runuser - "$RUNAS" -c "$CMD > $LOGFILE" cat $LOGFILE 

Agregue los derechos para ejecutar sudo chmod +x /etc/init.d/teamcity_agent y agregue la línea /etc/init.d/teamcity_agent start al archivo /etc/rc.local .

Control de reinicio, el agente ha subido, seguimos adelante.

Instalar Android SDK y emulador


Descargue las herramientas de Android SDK (solo herramientas de línea de comandos) y descomprímalo en el directorio deseado. Cree un directorio para almacenar futuras imágenes AVD (debe haber suficiente espacio). Para mí, los administradores han conectado el repositorio principal al directorio /var, y pondré todo allí. A continuación, cambiamos el propietario de los archivos a nuestro usuario y los siguientes pasos se realizan mejor con él.

 sudo chown tc_agent -R /var/opt/android-sdk sudo mkdir /var/opt/.android sudo chown tc_agent /var/opt/.android 

Agregar variables de entorno. Abra el archivo /home/tc_agent/.bash_profile para editarlo y escriba:

 export ANDROID_HOME=/var/opt/android-sdk export ANDROID_AVD_HOME=/var/opt/.android/avd export PATH=$ANDROID_HOME/platform-tools:$PATH export PATH=$ANDROID_HOME/tools:$PATH 

Reiniciamos y verificamos que las variables se muestran correctamente en la interfaz web de teamcity en la pestaña Parámetros del agente .

Intentamos ejecutar sdkmanager: el $ANDROID_HOME/tools/bin/sdkmanager --list debe enumerar los paquetes instalados y disponibles. Si obtiene un error como Exception in thread "main" java.lang.NoClassDefFoundError , pruebe esta solución .

Instale las herramientas necesarias y las imágenes de las máquinas virtuales.

 $ANDROID_HOME/tools/bin/sdkmanager emulator platform-tools tools $ANDROID_HOME/tools/bin/sdkmanager 'system-images;android-25;google_apis;x86' 

Crea y ejecuta AVD


Entonces, descargamos la imagen de 'system-images;android-25;google_apis;x86' (Android 7.1.1), creamos un dispositivo virtual basado en él. No entraré en detalles de todos los parámetros posibles de la utilidad avdmanager, lo mostraré en la cantidad mínima posible:

 $ANDROID_HOME/tools/bin/avdmanager create avd -n avd_name -k "system-images;android-25;google_apis;x86" 

Transferimos el nombre y la imagen original (debe descargarse previamente a través de sdkmanager). Si el error regresa, agregue la bandera -v para ver el texto.

Pasamos al emulador. Primero, verifique el emulador, plataformas, herramientas de plataforma, carpetas de imágenes del sistema en el directorio SDK. Creé plataformas con mis manos, el resto se creó al instalar paquetes a través de sdkmanager. A continuación, verifique la aceleración de hardware. Debería haber tal respuesta.

 $ANDROID_HOME/emulator/emulator -accel-check accel: 0 KVM (version 12) is installed and usable. accel 

Si hay un error al acceder a /dev/kvm , agregue los derechos:

 addgroup kvm usermod -a -G kvm tc_agent chown root:kvm /dev/kvm 

Además, todavía necesitaba instalar QEMU: sudo apt-get install qemu-kvm
Realice un nuevo inicio de sesión y vuelva a comprobar el emulador.

Si todo está bien, intente ejecutar. Para ver a través de los ojos, conéctese al servidor a través de vnc. Y ejecuta el emulador:

 $ANDROID_HOME/emulator/emulator @avd_name 

La siguiente ventana debería aparecer:


Durante las ejecuciones de prueba, ejecutaremos sin gráficos, por lo que agregaremos el parámetro -no-window .

Configurar compilación en TeamCity


Pasamos a la etapa final: configurar un lanzamiento autónomo de nuestras pruebas. Obtuve una compilación de 4 pasos.

1. Iniciando el emulador

 nohup /var/opt/android-sdk/emulator/emulator @avd_name -no-snapshot-save -no-boot-anim -no-window -snapshot clean_snap_1 > start_emulator.log 2>&1& 

Dado que el emulador "bloquea" el terminal, debe desatar el proceso utilizando la utilidad nohup (puede hacerlo de otra manera, usted decide). Por si acaso, guarde el registro del emulador en el archivo start_emulator.log . Para ejecutar las pruebas, creé una instantánea limpia (vea aquí cómo hacerlo) y agregué el interruptor -no-snapshot-save para que no se sobrescribiera.

2. Esperando a que el dispositivo arranque.

 adb wait-for-device shell 'while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;' 

Primero, esperamos el estado de wait-for-device , luego en el bucle esperamos cuando la variable sys.boot_completed devuelve 1.

3. Ejecución de pruebas. Aquí todo es individual, aquí está mi ejemplo:

 ./gradlew clean connectedAndroidTest 

4. Cierre el emulador. Aquí he hecho una simple terminación del proceso.

 kill -s 2 `pgrep qemu-system` 

Pero, por supuesto, es mejor recordar la ID del proceso al crear el emulador. Esto será necesario cuando comencemos a ejecutar las pruebas en varios subprocesos, lo que accidentalmente no "mata" el proceso incorrecto.

Eso es todo, gracias por leer. Si hay comentarios de colegas más experimentados, con gusto haré cambios en el manual.

Source: https://habr.com/ru/post/es415769/


All Articles