Servidor Kaspresso y ADB. ¡Hola a todos! | de Senchurin Nick | julio 2022

¡Hola a todos! Continuamos nuestra serie de artículos sobre Kaspresso. Este es el primer artículo de la sección avanzada, donde hablaremos sobre los detalles y matices de la implementación de funciones de Kaspresso. Si comparamos los marcos de automatización existentes, la ejecución de comandos ADB a menudo se ve como una ventaja para Appium. Sin embargo, esto está ausente en Espresso y UI Automator.Imagen de https://habr.com/ru/post/594017/ Intentamos arreglar esto en nuestro marco Kaspresso y agregamos un servidor ADB del que hablaremos. Entonces vamos. Espresso y UI Automator son la base de Kaspresso, lo que significa que si hubiéramos cambiado de Appium, habríamos perdido nuestra característica esencial: interactuar con el dispositivo a través de ADB. Esto plantea la pregunta: ¿por qué necesitamos ADB si pasamos las pruebas? La respuesta es: ADB no solo se limita a ejecutar comandos estándar como instalar aplicaciones, descargar archivos del dispositivo o instalar configuraciones del sistema, sino también muchos otros. Por ejemplo, los ingenieros de Google ejecutaron un comando: adb emu, que solo funciona con emuladores. Este comando inicia un servicio telnet en el emulador que le permite administrar el estado interno del dispositivo y hacer cosas no estándar como:

• ajuste de posición geográfica;
• Simulación táctil del escáner de huellas dactilares;
• conexión a internet inestable;
• llamadas telefónicas;
• envío de SMS;
• y muchos otros.

Esto es todo lo anterior: una emulación completa de las llamadas al sistema. En la aplicación, no es necesario que intentes simular la ausencia de Internet, ya que gracias a ADB, el sistema mostrará cómo sucederá esto en un dispositivo real. Así que nos aseguramos de que este sea el verdadero negocio. Continuo.

¿Por qué es posible usar adb en Appium pero no en Espresso?

El esquema de prueba con Appium se ve así:

1. La aplicación que estamos probando está instalada en el dispositivo.
2. Las pruebas de IU que hemos cubierto para nuestra aplicación se colocan en la máquina.
3. Se inicia el selenio.
4. Selenium inicia Appium Server.
5. Appium Server instala Bootstrap en el dispositivo.
6. Bootstrap se comunica con Appium Server a través de ADB.

Entonces, mientras se ejecutan las pruebas, la computadora y el dispositivo móvil se comunican constantemente a través de ADB. Esto nos permite usar ADB en las pruebas que necesitamos.

¿Qué sucede cuando escribimos pruebas usando el marco Espresso?

1. La aplicación que estamos probando está instalada en un dispositivo móvil.
2. Test APK con pruebas está instalado en el dispositivo móvil.
3. La computadora recibe el comando Ejecutar pruebas a través de ADB.
4. La aplicación y el APK de prueba se comunican entre sí.

Como podemos ver en este esquema, después de ejecutar las pruebas, la computadora no participa en el proceso de ninguna manera, todo sucede exclusivamente del lado del dispositivo. Entonces llegamos a la conclusión de que no se puede usar ADB.¿Cómo podemos compensar la pérdida?Hubo un momento de epifanía: enviar una acción «Ejecutar comando ADB» directamente desde la prueba. Investigamos la documentación y descubrimos que un enrutador virtual comienza con un rango de direcciones en todos los emuladores, una de esas direcciones es 10.0.2.2.Si accede al emulador usando la dirección IP 10.0.2.2, accederá al host local de su computadora. Una vez que descubrimos eso, intentamos construir un servidor usando el marco Flask. Así imaginamos el esquema de interacción:

1. Del lado del dispositivo, la aplicación se comunica a través de la dirección http://10.0.2.2, con el comando ADB especificado en el parámetro cmd.
2. En el lado de la computadora, un servidor que se ejecuta como localhost maneja la solicitud.
3. El comando ADB especificado en cmd se ejecuta en el lado de la computadora.

Escribimos las primeras pruebas, los comandos ADB llegaban a la computadora y los ejecutaba. Éramos felices hasta que…Imagen de https://habr.com/ru/post/594017/ En el caso de prueba, no encontramos la línea «Apagar Internet».Imagen de https://habr.com/ru/post/594017/¿Por qué pasó esto?Como sabemos, Android se basa en el sistema operativo Linux. Entonces, si tenemos un escenario donde Wi-Fi y la red celular están habilitados, podemos interactuar con el shell y obtener información sobre las interfaces activas.Entonces, además de localhost, tenemos Wi-Fi [wlan0] y datos móviles [radio0] interfaces Pero en cuanto activamos el modo avión, la situación empeora mucho.Perdemos las interfaces necesarias, y las pocas que quedan no nos permiten trabajar con un router virtual instalado en emuladores. Llegamos a la conclusión de que habíamos perdido la característica importante. Volvimos a la documentación y encontramos algo extraño: reenvío de puertos.Funciona así:

1. El servidor se inicia en el dispositivo, como en este ejemplo, en el puerto 7100.
2. El comando adb reenviar tcp: 6100 tcp: 7100 se lleva a cabo en la computadora.
3. Conectamos la computadora a la dirección localhost específica en el puerto: 6100 y obtenemos acceso al servidor creado en el dispositivo móvil.

eso es notable reenvío de puertos funciona incluso sin internet: los puertos se enrutan a través de la conexión del emulador. Por ejemplo, si el dispositivo está conectado a través de USB, los puertos se enrutan a través de USB; Si están conectados a través de Wi-Fi, se enrutarán a través de Wi-Fi. No importa qué interfaces estén actualmente activas en el dispositivo. También en contraste con el Delantero ordena que adb invertido existe el comando. Le permite realizar una solicitud HTTP al host local del dispositivo desde la aplicación colocada en el dispositivo, pero en realidad se conecta a la computadora. Es decir, hace exactamente lo contrario. Sin embargo, este comando tiene una limitación: solo funciona con Android 5.0. Esto no nos gustó nada ya que tuvimos que probarlo en dispositivos con Android 5.0.

El último esquema utilizado en Kaspresso

Brevemente sobre la idea básica: Empezamos a despegar adbserver-desktop.jar en el lado de la computadora. Este es un cliente que ayuda a administrar los dispositivos conectados. Las pruebas de Kaspresso se ejecutan en los dispositivos. Entonces la pareja adbserver-desktop.jar en el lado de la computadora y Kaspresso en el lado del dispositivo aseguran el flujo de trabajo para el siguiente esquema:

1. Seleccionamos el puerto del dispositivo. Siempre habrá una conexión en el lado del dispositivo, por lo que siempre podemos configurar el mismo puerto. Que sea: 8500.
2. Puede haber varias conexiones a la computadora porque se pueden conectar varios dispositivos al mismo tiempo. Se crea un único puerto libre del rango 6000..49000 para cada conexión. Por ejemplo, conectamos dos dispositivos y seleccionamos puertos :6100 y :48999 para ella o
3. En la computadora empujamos los puertos a cada dispositivo con los comandos: adb -s reenviar dispositivo1 TCP:6100 TCP:8500adb -s reenviar dispositivo2 TCP:48999 TCP:8500
4. Creamos clientes socket con las direcciones anfitrión local: 6100 y anfitrión local: 48999 en el lado de la computadora. Por si acaso, un recordatorio de que si el cliente y el servidor están ubicados en la misma dirección, se establece una conexión de socket entre el cliente y el servidor. Es decir, los clientes creados esperan a que se inicie el servidor de socket. anfitrión local: 6100 y localhost:48999 direcciones como se mencionó anteriormente.
5. Y ahora viene el truco principal. Empujamos puertos :6100 y :48999 de la computadora a puerto :8500 Dispositivos. Esto significa que los clientes de socket creados en realidad están esperando al servidor en la dirección localhost:8500 del lado del dispositivo y no del lado del dispositivo. anfitrión local: 6100 y anfitrión local: 48999 direcciones en el lado de la computadora.
6. En cada dispositivo iniciamos el servidor de socket con el anfitrión local: 8500 Dirección.
7. Establecemos una conexión de socket en el dispositivo. anfitrión local: 8500 dirección , donde hay un cliente y un servidor. Al mismo tiempo, recordamos que el cliente de socket está ubicado físicamente en el lado de la computadora (anfitrión local: 6100 y anfitrión local: 48999). La comunicación adicional tiene lugar a través de una conexión de enchufe. Puede haber ocasiones en las que necesitemos ejecutar un comando ADB en el dispositivo. En este caso, le decimos a la computadora este hecho y transmitimos una cadena en el canal. La computadora ejecuta físicamente este comando especificando el dispositivo y envía una respuesta a través del canal, una cadena que contiene el estado.

Cuando se han ejecutado los comandos, la retroalimentación proviene del servidor. Debido a este hecho, se agrega sincronicidad al esquema. Y también es útil, por ejemplo, cuando necesitamos transferir archivos grandes porque obtendremos comentarios después de ejecutar el comando. Resumen: ahora podemos ejecutar comandos ADB en Kaspresso cuando el dispositivo está conectado a la computadora de alguna manera (a través de Wifi, Bluetooth o USB). Eso es todo por ahora. ¡Manténganse al tanto!