Detox: La Estabilidad de Pruebas Inalcanzable (¿o no?)

Hola a todos. Comenzaré un poco con la motivación de esta charla. Detox es una solución de pruebas de caja gris para aplicaciones móviles. Gestiona la sincronización entre el código de prueba y la aplicación, por lo que los usuarios no tienen que hacerlo manualmente. A pesar de eliminar la necesidad de los usuarios de hacerlo y la abundante documentación y guías, los desarrolladores y probadores aún pueden tropezar con malos patrones de uso, mala configuración y sufrir de una baja estabilidad de las pruebas. Y sentimos este dolor todos los días internamente en Wix.

Así que en esta charla, pretendo explicar cómo Wix utiliza Detox internamente y cómo gestionamos la configuración, cómo luchamos contra la inestabilidad, y algunas de las mejores prácticas que hemos desarrollado durante casi tres años construyendo y utilizando Detox en nuestro proceso de integración continua. También discutiremos el impulso interminable hacia la eliminación de las pruebas manuales de control de calidad, que siempre parece enriquecido si solo superas ese último obstáculo técnico.

Hola, soy Rotem. Soy un ingeniero de software que trabaja en Wix. En los últimos cuatro años, he estado trabajando en Detox desde su inicio. En los últimos dos años y medio, lideré el equipo detrás de Detox. Y recientemente, dejé este puesto para unirme al grupo de infraestructura de servidores de Wix. En la foto, puedes verme con dos de mis proyectos secundarios favoritos, especialmente ahora durante el tercer confinamiento total en Israel.

Para que todo esté en el contexto adecuado, comenzaremos desde el principio. Detox fue creado en Wix para resolver un problema creciente con las pruebas inestables de extremo a extremo, especialmente en nuestra entonces nueva aplicación de React Native. La idea principal era seguir el enfoque ejecutado con éxito por Espresso y Earl Grey. Estos son dos proyectos de pruebas de caja gris creados por Google para Android e iOS respectivamente. A diferencia de las pruebas de caja negra, donde el probador necesita decidir cuánto tiempo espera a que la aplicación termine lo que está haciendo antes de enviar la siguiente acción o expectativa, el enfoque de caja gris incluye ejecutar un mecanismo de sincronización dentro de la aplicación en prueba para detectar la ocupación y la inactividad del proceso. Luego, solo interactúa con la aplicación cuando se considera inactiva. Esto significa que no tiene más eventos que manejar, no hay más solicitudes de red, no hay más animaciones, no hay más transiciones, en realidad no está haciendo nada. Este enfoque garantiza que cualquier acción o expectativa que se realice con la aplicación solo ocurrirá cuando la aplicación termine de procesar todo y nada cambiará más hasta la próxima acción del usuario.

Para hablar de cómo incorporamos las pruebas de extremo a extremo en Wix, también debemos discutir cómo está diseñada la aplicación móvil de Wix. En resumen, hay cuatro tipos de partes con las que construimos la aplicación. La primera parte es lo que llamamos el motor. Es el corazón de la aplicación, que incluye todo el código nativo y el registro de API para todos los módulos que se construyen sobre él, para que puedan comunicarse entre sí y con el motor. Las bibliotecas de infraestructura utilizadas con el motor, la mayoría de las cuales son de código abierto, y el propio motor están escritas en lenguajes nativos de la plataforma, como Objective-C y Swift para iOS, y Java y Kotlin para Android. Además, todo esto está envuelto con una API unificada de JavaScript.

El segundo tipo es nuestra biblioteca de UI, también conocida como React Native UILib. Este es un proyecto de código abierto y es el proyecto sobre el cual se construye toda la interfaz de usuario, incluyendo una gran cantidad de componentes de JavaScript y nativos. Un módulo es un producto individual, como un blog o una tienda. Tenemos muchos de ellos en la aplicación, como CRM y chat. Estos exponen una API a los consumidores y también consumen la API del motor y de la biblioteca de UI para construir su propia interfaz de usuario, junto con otros módulos. Esta es la implementación real del producto, donde se encuentran la mayoría de las pantallas y la lógica empresarial, todo definido dentro de un módulo. El cuarto tipo son otras bibliotecas, ya sea de código abierto o cerrado. Estas están algo desconectadas del proceso de lanzamiento, ya que son dependencias transitivas de las partes mencionadas anteriormente. Las nuevas versiones se actualizan manualmente con estas bibliotecas, principalmente a través de solicitudes de extracción al motor, a la biblioteca de UI o a un módulo. En cuanto a las pruebas, se prueban y se tratan por separado con su propio proceso de construcción y sus propios conjuntos de pruebas. Cada una de estas partes tiene su propio proceso de CI independiente y, cuando todo parece estar bien, se puede publicar una nueva versión para que todos la usen. La etapa final consiste en tomar todas estas partes con los archivos de configuración y construir un solo binario que incluya todo. Esta es la aplicación que se publica en Google Play y en la App Store.

Ahora que tenemos una idea general de cómo está estructurado todo, hablemos de las pruebas. No discutiré las pruebas unitarias porque, aunque tenemos muchas en todos los proyectos y se ejecutan todo el tiempo, en su mayoría son muy fáciles y económicas de ejecutar. En cuanto a las pruebas de extremo a extremo, diferenciamos entre varios tipos de pruebas y las dividimos en diferentes conjuntos de pruebas que se ejecutan en diferentes momentos y etapas del ciclo de desarrollo. Aquí hay cuatro tipos de pruebas de extremo a extremo que tenemos. El primero son las pruebas de extremo a extremo de producción. Estas son completamente funcionales y se ejecutan en una aplicación completamente funcional con una mínima simulación. Wix utiliza muchos experimentos y pruebas A-B en todas partes, y con este tipo de pruebas queremos asegurarnos de obtener las mismas características y pruebas en cada ejecución de prueba, ya que pueden diferir en diferentes ejecuciones de la aplicación. Por lo tanto, desarrollamos un mecanismo de anulación de experimentos que permite la configuración de un conjunto predefinido de experimentos al comienzo de cada prueba, lo que permite que la aplicación se inicie con estos experimentos en ejecución, asegurando así que nunca obtengamos un comportamiento diferente mientras la aplicación está siendo probada.

Las pruebas de extremo a extremo de producción se ejecutan cuando un propietario de módulo desea publicar su propio trabajo en la aplicación completa. Estas pruebas son en realidad solo con puntos finales de servidor simulados y pueden ejecutarse en un módulo específico o en toda la aplicación. Por lo general, solo lo hacemos en un solo módulo. No interactúan con entornos de producción, lo que controla el servidor simulado y nos permite controlar las salidas y pruebas del servidor simulado. Y prueba el comportamiento real del módulo con estados predefinidos. La gran ventaja es la capacidad de controlar todas las entradas de la prueba y tener entradas consistentes con el servidor simulado local, lo que garantiza una salida consistente de las pruebas, generalmente más estable y un poco más rápida que las pruebas de extremo a extremo de producción, y se ejecutan en CI en cada envío al código base de los módulos.

También incorporamos pruebas de captura de pantalla, que se utilizan principalmente en nuestra biblioteca de interfaz de usuario compartida, la librería de UI. Detox no tiene ningún mecanismo de comparación de capturas de pantalla, solo sabe cómo tomar capturas de pantalla a pedido. Sabemos cómo hacer capturas de pantalla a nivel de dispositivo y a nivel de elemento para compararlas con bibliotecas externas, utilizamos herramientas de Apple para obtener comparaciones inteligentes y evitar falsos positivos en ligeras variaciones de píxeles. Vale la pena mencionar aquí que las ligeras variaciones de píxeles no son un problema poco común. Puede ocurrir al comparar capturas de pantalla tomadas con dos tarjetas gráficas o controladores diferentes, por ejemplo. Por lo tanto, si tomas algo con el entorno de desarrollo local y tratas de establecer una línea base en esa máquina y luego ejecutas la prueba en la máquina de CI, tendrás capturas de pantalla diferentes. Esto puede fallar fácilmente y no manejarse correctamente.

La prueba de componentes es otro tipo de prueba que se realiza. Algunos de los módulos incorporan pruebas de los estados reales de los componentes de React. Estos cargan componentes con sus propios estados y luego cambian el estado y las props programáticamente a lo largo de la prueba. Esto se realiza sobre Detox con Compot, nuestra biblioteca de pruebas de componentes de React Native. Y estas se ejecutan en CI en cada envío al código base del módulo, al igual que hacemos con las pruebas de extremo a extremo simuladas.

Entonces, ¿cómo elegimos qué probar? Los módulos de la aplicación de Wix están escritos al 100% con JavaScript o TypeScript. Esto significa que la mayor parte de la lógica empresarial del módulo se ejecuta con el mismo código en las dos plataformas. Muchas veces, los desarrolladores de productos encuentran errores relacionados con el módulo en ambos plataformas de manera similar. Por lo tanto, los errores que se manifiestan solo en una plataforma generalmente son problemas con una biblioteca de infraestructura. Esto significa que los desarrolladores de módulos pueden obtener una cobertura bastante buena ejecutando solo pruebas de extremo a extremo en una plataforma sobre su módulo. Sin embargo, esto no significa que se pueda probar toda la aplicación en una plataforma. Todas las bibliotecas de infraestructura de Wix se prueban en iOS y Android. Por lo tanto, para confiar en las pruebas de extremo a extremo, deben ser muy estables, pero también proporcionar una buena comprensión de lo que sucedió y por qué falló la prueba. A lo largo de los años, hemos tratado de mejorar esto de dos maneras. La primera es mediante el desarrollo de una serie de herramientas que nos ayuden a entender las cosas, como volcados de jerarquía de vista, registros de seguimiento, videos, línea de tiempo de prueba, gráficos, y también tratando de facilitar a los usuarios la comprensión de por qué las pruebas se bloquean cuando lo hacen, y generalmente esto se debe a algún tipo de algo que mantiene la aplicación no inactiva, ya sea una animación o una solicitud de red o algo similar.

El segundo es la educación, y este último fue dirigido principalmente internamente al equipo de ingeniería de Wix, pero parte de él también llegó a nuestra documentación. Así que quiero hablar un poco sobre el segundo. Dos cosas que son muy importantes para nosotros cuando queremos tener pruebas estables de extremo a extremo son el aislamiento de pruebas y la consistencia de entrada. Queremos asegurarnos de que cada prueba comience desde cero, asegurarnos de que no dependa de la ejecución de una prueba anterior.

El segundo es la consistencia de entrada. Una aplicación puede tener múltiples entradas que pueden cambiar el comportamiento al ejecutar diferentes respuestas de los servidores. Algunas aplicaciones pueden tener experimentos y pruebas A-B que se ejecutan en diferentes rutas de código en la aplicación, lo que hace que se comporte de manera diferente durante diferentes ejecuciones. Por lo tanto, debes asegurarte de que se manejen y configuren en tus pruebas, y que sean idénticos en todas las iteraciones de esas pruebas, ya sea localmente o en CI. Al menos hemos desarrollado un mecanismo de anulación de experimentos que nos ayuda a predefinir esos experimentos y asegurarnos de que funcionen bien mientras la aplicación está siendo probada.

En cuanto a la configuración, a medida que Detox se vuelve más maduro, obtenemos más características e integración más estrecha con Jest, lo que generalmente hacemos para aprovechar algunas características disponibles en Jest o nuevas características interesantes en Detox. Estas configuraciones se vuelven más difíciles de manejar. Aunque la documentación en sí es bastante buena, es muy difícil hacer un seguimiento de la configuración. Como se mencionó antes, en realidad, estos son todos los archivos de configuración que tenemos en Detox, en uno de nuestros proyectos internos. Como se mencionó antes, la aplicación de Wix está construida a partir de muchos módulos desarrollados de forma independiente. Cada uno tiene sus propios proyectos de git y configuración de compilación en CI, y cada uno de ellos tuvo que agregar los archivos de configuración de Detox a su propio repositorio. La mayoría de ellos eran archivos de configuración similares, y durante los últimos seis meses, nos dimos cuenta de que no tiene sentido mantenerlos de esta manera. Así que unificamos la configuración para todos. Creamos una biblioteca que nos ayuda a compartir todo. Estos archivos de configuración son una parte extremadamente importante pero frágil de Detox. Es fácil configurarlos incorrectamente, y cuando están mal configurados, obtienes resultados deficientes. Por estas razones, hemos decidido proporcionar algún tipo de configuración básica compartible con Detox directamente desde el principio con el Detox de código abierto. Esperamos hacer esto en un futuro cercano. Esto es algo que ya hacemos internamente. La integración continua para dispositivos móviles es una de esas cosas que todavía es bastante difícil de lograr con una solución lista para usar. Hemos probado todas las principales soluciones de CI SUS ejecutando pruebas de extremo a extremo en iOS en CircleCI, Travis o Bitrise. Es bastante fácil.

Y el gran problema estaba con los emuladores de Android. La verdadera idea aquí es que los emuladores de Android funcionan mejor en las VM de Mac que en las ofrecidas en Linux. Están garantizados para ejecutarse con virtualización anidada en Mac, lo cual es necesario para ejecutar emuladores x86. Básicamente, ejecutamos una VM, el emulador x86 de Android dentro de una VM que es el sistema operativo Mac, por lo que requiere virtualización anidada. Sin embargo, aún carecen de aceleración de hardware y el rendimiento del emulador resultante es deficiente, aunque funciona.

Por lo tanto, la solución actual para nuestra CI interna incluye VMware ESXi en Mac Pros en el estadio InMix con VM de Mac OS. Estos funcionan tanto para iOS como para Android, ya que VMware admite virtualización anidada. Pero el rendimiento de esas máquinas sigue siendo bastante malo. El tiempo de compilación es lento y la paralelización de pruebas está algo limitada. No podemos usar muchos simuladores o muchos emuladores en la misma máquina. Y con eso, ralentizamos o no ralentizamos la cantidad de tiempo que se tarda en ejecutarlo.

Por lo tanto, nuestra configuración de próxima generación incluye Mac minis de metal desnudo que ejecutan todo en el sistema operativo host. Estos tienen un rendimiento mucho mejor, al menos dos veces más rápido que las VM en un Mac mini basado en Intel. Esperamos poder hacerlo aún más rápido con los Mac minis con chip M1. En cuanto a los emuladores de Android, recientemente lanzamos soporte para dispositivos Genycloud SAS y orquestamos todo eso con D-talks directamente desde el principio. Al utilizar emuladores Genycloud, obtenemos cuatro beneficios clave. El primero es que eliminamos todos los requisitos previos para las máquinas de CI, ya que estos emuladores se ejecutan de forma remota en la infraestructura de Genycloud. El segundo es que obtenemos un mejor rendimiento por emulador individual. En nuestro caso, se redujo una suite de 35 minutos con dos trabajadores ejecutando emuladores de Android a 15 minutos con dos trabajadores ejecutando emuladores de Genycloud. El tercero, y quizás el mayor beneficio, es la capacidad de escalar infinitamente y ejecutar tantos trabajadores como queramos en paralelo. Por lo tanto, todas las opciones de CI como servicio que mencionamos ahora son válidas, ya que se pueden utilizar para compilaciones y orquestación de pruebas y descargar toda la emulación de dispositivos a Genycloud. El principal inconveniente de Genycloud es que es un servicio de pago, incluso para proyectos de código abierto. Por lo tanto, el Santo Grial para el proceso de lanzamiento es tenerlo todo automatizado y rápido. A medida que continuamos resolviendo nuestros problemas, nos acercamos un poco más al objetivo en cada paso. El principal problema al que nos enfrentamos hoy es la velocidad de ejecución de las pruebas en CI, especialmente para pruebas elaboradas de extremo a extremo. Esto es absurdo. Lo absurdo es que es más rápido para nuestros ingenieros de QA revisar manualmente la suite de pruebas que esperar 150 minutos para que todo termine. Así que eso es lo que hacen. Sin embargo, esto no durará mucho. Con un poco más de trabajo, obtendremos pruebas mucho más rápidas con una ejecución potencialmente infinita.

Gracias. Gracias por tenerme, Alex. ¿Qué opinas de la encuesta? Sé que Detox estaba en la parte superior y esperaba que Detox fuera el número uno, ¿qué opinas de la otra parte? Bueno, supongo dos cosas. Una es que me pregunto cuál es la otra, por supuesto, y la segunda es que sé que Detox probablemente sea la primera opción cuando se trata de aplicaciones de React Native, pero cuando se trata de aplicaciones nativas o aplicaciones escritas en diferentes frameworks, entonces veo sentido en usar algo que no sea Detox. Así que sí, no es una sorpresa total, supongo, pero la otra parte es muy interesante.

Eso tiene mucho sentido. El punto sobre Detox siendo una herramienta realmente específica del framework, y eso se vio en tu charla. Tengo un montón de preguntas de muchas personas. No voy a mencionar sus nombres, me voy a enfocar en las preguntas que nos hicieron durante tu charla. No olvides que si tienes preguntas para Rotem, aún puedes ir al canal de preguntas y respuestas en Discord y hacer una pregunta. La primera fue, comencé a trabajar con Detox recientemente. Es bastante fácil comenzar con la guía de inicio, pero ¿qué pasa con flujos más difíciles, como el uso de funciones del dispositivo como la cámara, desactivar Internet, bloquearlo, y desbloquear el dispositivo? Hay muy pocos materiales sobre Detox en comparación con otras herramientas. ¿Dónde y cómo puedo aprender mejor Detox? Esa fue una gran pregunta. Así que empecemos por algo pequeño. ¿Cómo puedo desactivar y activar cosas en el dispositivo, como bloquearlo y desbloquearlo con Detox?

Sí. Bueno, veamos. En cuanto a iOS, Detox aún admite simuladores y aún no se ejecuta en dispositivos reales. Tenemos un plan y lo que hicimos con Detox17 y Detox18 es prepararnos para ejecutarnos en dispositivos reales en iOS. Ahora eso no resuelve el problema de desconectar la red y desactivar cosas similares a eso. Y en realidad, no estoy seguro de qué tiene esta capacidad. Según entiendo, solo sería una especie de simulación de la capa de red y de alguna manera. En Android es un poco más factible, pero sí, no lo tuvimos en cuenta al desarrollar Detox. Por lo tanto, no usamos realmente esas funciones, pero si crees que es una característica súper importante que realmente deseas y consideras muy importante, entonces, por supuesto, vamos a discutirlo en nuestros problemas de GitHub y veamos cómo podemos hacer que esto suceda.

Eso es un punto muy válido. Recuerdo de mis días de testing, que no siempre intentábamos probar la interacción con el dispositivo. La aplicación era lo más importante. La aplicación era el objeto de nuestra prueba, ¿verdad? Lo que sucedía con el teléfono mientras usábamos la aplicación no era realmente el propósito de la prueba. ¿Y qué hay de los materiales? ¿Dónde pueden las personas encontrar materiales avanzados sobre Detox? Creo que los documentos son, quiero decir, hay mucha documentación. Y si vas, encontrarás gemas bastante buenas allí.

Estoy bastante seguro de que hay mucho contenido cubierto en la documentación. También hay cosas que escribí anteriormente en Medium de Wix que creo que son un poco diferentes a lo que está en la documentación. También puedes ir y leer eso. Cosas relacionadas, recientemente publiqué esta semana, al comienzo de la semana, una publicación en el blog sobre cómo hacemos que nuestras pruebas sean súper estables internamente en Wix. Entonces, ¿cuáles son las reglas básicas para hacer pruebas súper estables? Y repaso todo tipo de características que nos ayudan a lograr eso.

Ahora, todo tipo de recopilación de artefactos, artefactos que recopilamos durante las pruebas para asegurarnos de entender qué está sucediendo durante las pruebas, especialmente cuando las pruebas fallan. Y creo que estos también son buenos materiales. Y mencionaste cosas sobre la documentación de, ¿qué era eso? Sobre las funcionalidades del dispositivo y la red, como simular la red, una mala red, algo que realmente no tenemos. ¿Cuáles eran las otras cosas, Alex?

Creo que los ejemplos mencionados específicamente eran características del dispositivo como desactivar la cámara, desactivar Internet y bloquear y desbloquear el dispositivo. Entonces, la cámara es algo que... Me gustaría saber sobre la cámara, sí. No veo problemas específicos con la cámara. Si tienes un módulo de cámara en tu aplicación, simplemente puedes abrirlo. Si ejecutas un emulador, puedes asegurarte de que esté conectado a la cámara o a una cámara simulada que proporciona el emulador de Android. Si es Genymotion, hace lo mismo. Si es un dispositivo real, también puede abrir la cámara. Entonces, si tienes un módulo de cámara en tu aplicación y lo abres, debería funcionar sin problemas. No hay nada que desactivemos para que funcione, según entiendo. Entiendo. Entonces, ¿cómo manejas cosas como, por ejemplo, mi teléfono tiene tres cámaras? Es un iPhone nuevo. Tiene tres cámaras. Tengo que seleccionar qué cámara quiero en cada aplicación que usa la cámara, ¿verdad? Si uso la linterna, por ejemplo. Oh, sí. Supongo que hay dos tipos de cosas que quieres agregar. Si tienes, hay una forma de ir a la aplicación de la cámara y tomar una foto. Y esto es algo en lo que Detox generalmente se concentra en la aplicación con la que le permites trabajar. Entonces es tu aplicación, no otras aplicaciones del sistema. No quieres probar realmente esas aplicaciones del sistema. Quieres probar tu propia aplicación.

Entonces, si quieres obtener imágenes que fueron tomadas con otras cámaras, con otras aplicaciones de cámara, entonces puedes ir y obtenerlas. Nuevamente, en tu aplicación, si hay una forma de ir a la galería y obtenerlas. Y la otra opción sería si tienes un módulo de cámara específico como los kits de cámara de React Native o algo similar que abre el módulo de cámara como una vista en tu aplicación. Y con esto, no creo que tengamos ninguna limitación. Creo que simplemente funciona.

De acuerdo, eso es muy bueno. Eso es muy bueno. Tenemos varias preguntas interesantes. Una de ellas dice, ¿cuáles son las mejores prácticas para solucionar problemas en las pruebas fallidas de Detox? Hay un comentario al final que dice que falla muy a menudo en nuestro pipeline, mientras que se ejecuta localmente está bien. Entonces, ¿cómo lidas con la solución de problemas en las pruebas fallidas? ¿Cuál es tu mejor práctica para eso? De acuerdo. Así es exactamente, creo. Hay una respuesta exacta a esto en la última publicación de blog que acabo de publicar esta semana. Nuevamente, utilizando todas las herramientas que proporcionamos, todas esas herramientas de recopilación de artefactos y comprendiendo la salida de las pruebas mismas, como las salidas de Detox en el registro. Y hay algunas reglas básicas para asegurarse de tener un buen entorno de pruebas, y esto también está escrito allí. Pero diría en pocas palabras, esto es algo con lo que terminé la charla, tener entradas consistentes. Para que puedas obtener resultados consistentes, eso es seguro para cualquier prueba, no solo para las pruebas de extremo a extremo, sino para todas las pruebas. No quieres tener diferentes horas en el reloj para cada prueba que ejecutes. No quieres tener diferentes entradas. Eso es un problema. Y el segundo sería tener pruebas aisladas. Será mucho, mucho más fácil para ti solucionar problemas cuando surjan, porque sabes que tu prueba comienza en una pantalla específica y no en una pantalla que realmente no conoces cómo llegaste allí. Si es como un residuo de una prueba anterior. Eso tiene mucho sentido. Eso tiene mucho sentido.

Hay una pregunta sobre los dispositivos que admiten Detox. Alguien dice que tenemos que ejecutar pruebas de Detox en emuladores en nuestro pipeline. ¿Existen soluciones para las granjas de dispositivos que admiten Detox? La ejecución en simuladores no brinda el mismo nivel de confianza que la ejecución en dispositivos reales. Correcto. Esta también es una respuesta larga. Así que la dividiré nuevamente para iOS y Android.

Entonces, para iOS, todavía admitimos solo simuladores, pero estamos trabajando en el soporte para dispositivos reales. Esto sería envolviendo o al menos agregando pruebas XEUI a la mezcla que sería lo que lanza Detox dentro de la aplicación de iOS. Entonces, para iOS, todavía no hacemos eso realmente. Aunque tenemos un plan con un gran proveedor de granjas de dispositivos, pero aún no es algo de lo que podamos estar seguros, o al menos no estar seguros de que sucederá, pero realmente queremos que suceda.

Y para Android, admite dispositivos y puedes ejecutar pruebas de detox en cada dispositivo conectado a tu computadora, solo tienes que ejecutar las pruebas de detox. Sé que no es lo mismo que ejecutar en una granja de dispositivos y esto no es realmente compatible. No hay una granja de dispositivos que admita detox de manera nativa, pero recientemente agregamos soporte, como soporte nativo para lanzar emuladores de Geny Motion. Estos son diferentes de los emuladores de Android. También son x86 pero se ejecutan en máquinas designadas en Geny Motion Cloud.

Entonces, para nosotros, sé que dijiste que no es lo mismo que ejecutar en dispositivos reales y estoy de acuerdo hasta cierto punto, aunque realmente no encontramos muchos problemas específicos de los dispositivos. La mayoría de los problemas que encontramos son en realidad problemas con la aplicación, con el SDK, niveles de SDK específicos. con Android. Pero el hecho de que ahora ejecutemos en Geny Motion Cloud. Comenzamos a hacerlo internamente en Wix y esto redujo nuestras pruebas de extremo a extremo de, digamos que estoy tomando un ejemplo. Una de las suites tardaba 35 minutos, bajamos a 15 minutos con el mismo número de trabajadores. Entonces tenemos los mismos dos emuladores que se ejecutan en esa máquina. Con Geny Motion pudimos ejecutar con dos trabajadores en Geny Motion Cloud solo en los 15 minutos para la misma suite de pruebas. Entonces es como una mejora del 60% en el tiempo de prueba. Sé que esto no es exactamente la respuesta que querías escuchar pero tenía que hablar de esto. Para ser honesto, tiene mucho sentido. Por ejemplo, donde estábamos ejecutando pruebas en muchas placas Panda en lugar de configurar dispositivos reales en racks. Lo intentamos por un tiempo pero no fue eficiente y las placas Panda nos dieron prácticamente el mismo resultado, así que estuvo bien.

Tengo tantas preguntas complicadas para ti. Me siento mal por elegir las complicadas. Así que tengo una simple, tu última pregunta del día y luego terminas conmigo. Tengo una pregunta realmente simple de sí o no. ¿Se puede usar Detox con X-Box React Native? De acuerdo, sí. Pero Expo se ha puesto en contacto con nosotros varias veces en el pasado. Para iOS, creo que debería funcionar con la configuración actual. No debería haber ningún problema según entiendo. Y con Android, en realidad depende de Expo proporcionar también un APK de prueba, un APK de prueba precompilado como lo hacen con el APK de producción.

Entonces, el APK de prueba es el APK que tiene Detox en su interior y sabe cómo conectarse a la aplicación de producción y hacer preguntas y conectarla al servicio Node que ejecutamos y hacer esas preguntas. Hablamos con Expo en el pasado, creo que hace unos dos años y se hizo, pero es algo que debe mantenerse cada vez que tenemos una nueva versión, realmente no tenemos cambios disruptivos en Android, al menos no en el último año, creo.

Entonces, cada vez que alguien lo configure en Expo, en la biblioteca en sí, sí, no como el proyecto. Cada vez que alguien del equipo de Expo lo configure, debería funcionar sin problemas.

Gracias, muchas gracias. Eso realmente tiene mucho sentido, la imagen tiene mucho sentido. Gracias Rothem, me divertí mucho con tu charla. La sesión de preguntas y respuestas fue realmente interesante. Muchas gracias, Rothem. Muchas gracias. Preguntas difíciles, gracias por eso. Sí, preguntas realmente difíciles, preguntas realmente difíciles. Gracias, muchas gracias. Gracias. Gracias. Gracias. Gracias. Gracias.