Maestro & Expo: Creando el Futuro de Pruebas e2e Eficientes

Hola, espero que estés bien. Soy Mathieu y es un placer estar aquí hoy. Voy a hablar sobre las pruebas end-to-end. Así que piensa en tu aplicación como un coche deportivo de alto rendimiento. No solo probarías el motor o los frenos o la dirección de forma aislada. Querrías sacarlo a dar una vuelta, ver cómo se desempeña en pistas en condiciones reales. Bueno, esa es la esencia de las pruebas end-to-end. Es como tu prueba de manejo. Examina tu aplicación en su totalidad, detectando esos errores difíciles de encontrar, especialmente en el código nativo, que las pruebas unitarias o de interacción podrían pasar por alto.

Tal vez hayas oído hablar de la pirámide de pruebas o el trofeo de pruebas. Siempre mencionan las pruebas end-to-end, pero la realidad es que he trabajado con diferentes clientes en YOLO apps y rara vez vi una buena configuración de pruebas end-to-end. Y la mayoría de las veces no hay pruebas end-to-end en absoluto. Y creo que eso se debe a que hay muchos puntos problemáticos.

Así que, en primer lugar, las pruebas end-to-end para mí siguen siendo complejas de configurar y usar. Me tomó más de una semana configurarlo con algunas herramientas. Las pruebas pueden ser poco confiables y va a ser molesto configurarlo correctamente en CI-CD porque tienes que construir la aplicación, iniciar los simuladores, tener el entorno adecuado. Y por último, pero no menos importante, casi siempre es lento y costoso ejecutarlas regularmente. Así que, mi charla de hoy es sobre mi experiencia en YOLO apps y cómo intenté solucionar todos esos problemas para tener la configuración perfecta de pruebas end-to-end.

Primero, probé Appium. Es una herramienta de pruebas end-to-end de caja negra. No hay necesidad de empaquetar o instalar nada dentro de tu aplicación. Simplemente le das la app, el APK. Y creo que es la herramienta más establecida y también la más poderosa. Appium puede replicar casi cualquier cosa que un usuario real pueda hacer.

Pero para mí también hay muchos inconvenientes. Es realmente complejo entender la documentación, configurarlo correctamente. Pasé mucho tiempo para tener mi primera prueba en funcionamiento. Hay una gran curva de aprendizaje y tampoco hay soporte CI-CD. Así que, tendrás que manejar los simuladores, la construcción, y así sucesivamente.

Luego probé Detox, que es una herramienta de pruebas end-to-end para React Native. Personalmente creo que son bastante similares. Quiero decir, Detox es un poco más simple y fácil de usar en general, pero por otro lado es menos poderosa. Y después de usar esas dos herramientas, me di cuenta de que todavía no es algo que vería a mi equipo y a mí usar todos los días. No abordan el punto problemático que mencioné anteriormente. Así que tuve que seguir investigando y finalmente descubrí Maestro. Maestro es una herramienta más nueva. Funciona en React Native y en todas las demás plataformas móviles. Creo que hay una comunidad realmente genial a su alrededor. Tienen un Slack donde responden preguntas muy rápidamente, por ejemplo. Pero la documentación es muy buena y en lugar de hablar de ello, voy a mostrarte cómo funciona.

Así que, aquí tengo una aplicación simple. Tengo un botón de información que abre el modal y puedo deslizar este modal hacia abajo y esta es la prueba que voy a intentar hacer con Maestro. Este tipo de pruebas es realmente difícil de hacer sin una herramienta de pruebas end-to-end. Con una herramienta de pruebas de integración regular como React Native Testing Library, usualmente tienes que registrar la navegación. Pero verás cómo lo hago. Lo primero que vamos a hacer es usar Maestro Studio. Es una herramienta que viene incluida con Maestro y es básicamente una interfaz web donde tu simulador está incrustado y puedo pasar el cursor sobre mi simulador y algunas zonas y algunos textos serán resaltados. Esta herramienta está aquí para ayudarme a construir, para ayudarme a crear mis pruebas.

Entonces, si hago clic en algo, verás que tengo algunas recomendaciones. Puedo tocar este botón, puedo tocar un test ID, puedo tocar un texto, incluso puedo tocar algunos puntos específicos en la pantalla. Creo que es un poco menos recomendado, pero aún puedes escribir automáticamente tu prueba rápidamente, incluso si no has configurado correctamente tus test IDs. Y puedo interactuar con todo en mi aplicación. También puedo hacer algunas afirmaciones si quiero.

Pero intentemos construir la prueba. Así que, voy a hacer clic en mi botón de información. La primera recomendación parece bastante buena. Así que, simplemente puedo seleccionarla y ejecutará esta acción y deberías ver el resultado en mi simulador. Sí, el modelo acaba de abrirse. Ahora, tal vez pueda verificar que el texto es visible. Así que, voy a la recomendación de afirmación y esta parece exactamente como quería. Así que, puedo seleccionarla y está pasando, como puedes ver con la marca de verificación verde. Lo siguiente que hay que hacer es cerrar el modelo de nuevo abajo. Y cuando hago clic en información, puedes ver que realmente no tengo ninguna buena recomendación. Quiero deslizarlo, no escribirlo, no tocarlo. Así que, simplemente puedo abrir los documentos. Verás que hay muchas acciones que puedes hacer con Maestro. Puedo afirmar que algo es visible, no visible, puedo ingresar algún texto fácilmente, puedo desplazarme dentro de mi aplicación, y también puedo deslizar. Así que, echaremos un vistazo a la documentación de deslizar.

Aquí, quiero desplazarme hacia abajo. Así que, este ejemplo parece bastante bueno. Y cuando encuentro algo que quiero, puedo copiarlo, volver a Maestro Studio, y simplemente puedo ingresar cualquier cosa que quiera aquí. Así que, pegaré esto, lo modificaré para que pueda agregar mis test IDs y cambiar la dirección. Y cuando termine, puedo ejecutar esta parte, y verás que mi modelo se desliza hacia abajo. Lo último que podemos hacer es afirmar que el texto del modelo ya no es visible. Hazlo con afirmar no visible. Y cuando termine, simplemente puedo seleccionar todo y exportarlo para que pueda simplemente crear esta prueba dentro de mi base de código. Así que, simplemente copiaré esto y volveré a mi aplicación. He hecho una plantilla de prueba a la que volveré más tarde.

Verás que hay una etiqueta aquí. Explicaré esto más tarde, pero básicamente, solo estoy pegando mi prueba aquí. Y sí, la prueba está abriendo la aplicación. Estamos haciendo clic en info, afirmando que algo es visible y deslizando hacia abajo. Así que, ejecuto la prueba en Maestro Studio, pero también puedo ejecutarla solo con Maestro. Así que, puedes ver lo que sucede cuando solo ejecuto mi prueba. El video no está acelerado. Así que, ese es el tiempo real de la prueba de Maestro. Y como puedes ver, la aplicación debería cerrarse y volver a abrirse. Y es muy rápido. Puedes verlo suceder al lado. La prueba pasó. Estoy bien.

Lo último que quiero mostrarte es otra herramienta de Maestro, que es Maestro Cloud. Y con un simple comando, puedo, en lugar de ejecutar las pruebas en mi máquina, puedo enviar las pruebas y mi Apica a los servidores de Maestro Cloud. Es su servicio en la nube. Y las pruebas se ejecutarán en sus servidores, en su simulador. No tengo que gestionar nada. Y puedo simplemente ir a su interfaz web y echar un vistazo a las diferentes ejecuciones. Así que, eso es muy genial, porque ellos se encargan de todo. Tienen reintentos automáticos si la prueba falla. Si falla, puedes echar un vistazo a qué paso falló. Y hay incluso algunos videos de la parte fallida de la prueba que te ayudan a entender qué salió mal.

Y, bueno, eso es todo para la demo de Maestro. Quiero decir, Maestro para mí fue algo que realmente resolvió muchos de mis puntos problemáticos. La instalación es súper rápida y es muy simple de usar. Nunca es perfecto, pero Maestro nos ayudó mucho con la inestabilidad. Y luego, bueno, ejecutarlo localmente es genial, pero CI CD aún está parcialmente abordado. Viste que puedo iniciar la prueba en Maestro Cloud desde mi máquina, pero aún no desde el CI. Todavía necesito construir mi aplicación primero en el CI.

todavía creo que necesitaba algo completamente automatizado para realmente involucrar a mi equipo. Por ejemplo, quiero algo que se pueda hacer automáticamente en una solicitud de extracción o cuando fusionas a master, por ejemplo. Así que intenté echar un vistazo a la documentación, a los artículos en línea, y vi que recomiendan reconstruir la aplicación para cada prueba. Y para mí, eso es un poco molesto. No quiero tener que construir mi aplicación durante el CI CD. Tendré que gestionar el caché, los entornos. Va a ser lento y costoso, también. Así que investigué más a fondo y finalmente me di cuenta de que en Theodore Apps, también usamos mucho Expo y puede ayudarnos aquí. Así que veamos cómo.

Resumen rápido sobre Expo. Es un conjunto de herramientas que te permite iterar más rápido. Incluso es recomendado por Meta ahora. Quizás algunos de ustedes usaron Expo Go antes. Es bueno para prototipos, pero no se recomienda en producción. Así que aquí usamos las compilaciones de desarrollo personalizadas. Es como mi compilación personalizada. La compilación de desarrollo personalizada es la capa nativa con el código nativo y las bibliotecas que necesitas más algunas cosas útiles de Expo al lado. Y esta capa nativa es como un contenedor dentro del cual inyectas tu capa de actualización. Así que puedes construir este contenedor localmente con Expo, que va a usar Xcode o Gradle y otros bajo el capó. Pero también puedes usar EAS, que son servicios en la nube de Expo. Y con solo un comando, la compilación se realizará en los servidores de EAS, lo que probablemente será más rápido que mi máquina.

Y una vez que construyes en los servidores de EAS, la compilación permanece disponible para todos en tu equipo. Y eso es realmente útil porque solo tienes que construir una vez y luego todos en tu equipo pueden simplemente descargarla. Así que esa es la capa nativa. Y así, dentro de esta capa nativa, puedes inyectar la capa de actualización, que básicamente es la capa de JavaScript. Es como el paquete de JavaScript que tienes cuando ejecutas start. Pero también puedes usar EAS para crear algunas capas de actualización y almacenarlas en los servidores de EAS. Aquí puedes ver que puedo inyectar fácilmente la última capa que se ha hecho en la rama de desarrollo dentro de mi capa nativa. Y significa que si mi colega tiene la capa nativa en su teléfono, puede descargar rápidamente la última actualización y ver cómo se ve la aplicación en desarrollo actualmente. Así que eso es lo que usamos para abordar mis problemas de CICD con Expo.

No necesitamos construir en cada pipeline, y esto lo hará rápido, barato y mucho más simple. Veamos cómo se ve la solución.

Aquí está lo que sucede cuando abro una pull request en mi proyecto. Estoy usando GitHub actions, pero puedes usar lo que quieras. El primer paso es crear y publicar la actualización en EAS. Significa que estoy empaquetando el código JavaScript y enviándolo a EAS. Cuando está hecho, y cuando se crea la actualización, mostramos un código QR que puedes escanear si tienes la capa nativa para ver el estado de mi app tal como está en mi rama de pull request, lo cual es muy útil incluso para el PR.

Y luego, en lugar de construir la app aquí, también podemos usar EAS. Luego simplemente descargo la última build que hice en EAS. Y aquí es donde vamos mucho más rápido que tener que reconstruir la app. Porque ahora tenemos todo lo que necesitamos. Tenemos el APK y podemos simplemente enviar cosas a MySQL Cloud.

El siguiente comando es el comando de MySQL Cloud que te mostré antes. Le doy la ruta a mi APK o archivo de app para iOS, y también un parámetro que es el ID de la actualización que hicimos antes. Lo que significa que ahora cuando la app se abre en los servidores de MySQL Cloud, se abre con un deep link apuntando a la actualización correcta de EAS. Luego buscará esta actualización de EAS. Y cuando está hecho, ahora la app tiene el mismo estado que está en mi rama de pull request.

Así que lo último que podemos hacer es ejecutar las pruebas y obtener el informe de vuelta a mi pull request. Estoy usando el hook de MySQL Cloud aquí para tener un buen informe. Y puedes ver aquí que mi CI completo tomó solo menos de cinco minutos. Así que creo que eso es muy genial. También puedo mostrarte lo que sucede cuando el CI falla. Así que puedo obtener más detalles aquí. Como puedes ver, mi propia prueba pasó, pero el modelo uno falló. Veamos por qué. Me llevará de vuelta a la interfaz de MySQL Cloud. Puedo ver que esta afirmación aquí es la que falló. Estaba deslizando hacia abajo, aparentemente. Así que para obtener más información, puedo simplemente iniciar el video. Debería ver la app que se abre.

Hago clic en el botón de información, el modelo se abre. Y sí, está fallando. Por alguna razón extraña en Android, el modelo no es un modelo agradable que aparece desde abajo, sino que nos muestra una página aquí, lo cual es extraño. Pero por eso te mostré este ejemplo, porque ese es realmente el poder de las pruebas end-to-end. Eso es algo que podrías pasar por alto fácilmente si solo pruebas en tu simulador. Y eso también es algo con lo que nunca habrías lidiado con las pruebas de integración regulares.

Así que para resumir con esta solución, tenemos un tiempo de CICD de cuatro minutos. Las pruebas son gratuitas y las actualizaciones de EIS son gratuitas. Mientras que si fueras a construir tú mismo en el CICD, tomaría mucho más tiempo. Tal vez tendrías que pagar el plan de producción de EIS para que puedas construir mucho, o tal vez si quieres construir tú mismo tendrías que lidiar con el almacenamiento en caché y el mantenimiento del CICD. Así que con eso, solucionamos cada punto de dolor.

En la última diapositiva de esta presentación, habrá un código QR donde puedes encontrar mi repositorio de ejemplo. Y por favor siéntete libre de usar para copiarlo para tus apps. Puedes ver allí cómo configuré mi CICD. Es muy simple. Antes de terminar, hablemos de algunos puntos de dolor. Maestro es una herramienta nueva. No tiene soporte para dispositivos iOS aún, solo simuladores. Tampoco hay soporte para dispositivos encontrados aún. Las pruebas se escriben en YAML, lo cual es molesto porque no es seguro para tipos y no es estándar. Pero también significa que escribir la prueba es fácil y tal vez tus propietarios de producto puedan hacerlo, o tal vez tus diseñadores puedan hacerlo también.

Y el límite de 100 pruebas gratuitas por mes, tal vez no parezca mucho, pero mi consejo es que deberías probarlo totalmente en tu proyecto. 100 pruebas por mes son suficientes para que te hagas una idea de si Maestro te ayuda o no. Y no tienes que ejecutar la prueba en cada pull request. Puedes ejecutarlas semanalmente o tal vez solo cuando publicas una actualización de tu app, por ejemplo. Si recuerdas antes, te mostré que puedes agregar etiquetas para la prueba. Así que una prueba con esta etiqueta significará que solo se ejecutará en cada pull request o solo se ejecutará semanalmente o solo se ejecutará antes de que despleguemos una actualización. Puedes ver cómo funciona en mi repositorio de ejemplo, pero esto significa que puedes elegir tu propia estrategia de pruebas. Tal vez si tienes una característica crítica de tu app, quieras probarla en cada pull request, pero las otras características que son menos importantes, tal vez solo puedas probarlas antes de desplegar una actualización. Y si quieres hacer más de 100 pruebas por mes, el precio es de 10 centavos por prueba y siempre puedes ahorrar más adelante si quieres. Bueno, eso es todo por mi parte. Muchas gracias. Si escaneas este código QR, puedes ver el repositorio de ejemplo y también las diapositivas. Puedes encontrarlo en mi GitHub. Por favor, no dudes en hacer cualquier pregunta en el chat o en mi Twitter. Y también puedes venir a echar un vistazo a lo que hacemos en Theodore Ops. Muchas gracias. Adiós.