Pruebas en Dispositivos Móviles para Aplicaciones Multiplataforma

Entonces, sí, esto es prueba de dispositivos móviles para aplicaciones cross-platform. Como probablemente ya hayan escuchado, soy Cecilia Martinez. Soy defensora de desarrolladores para AppFlow, que es una plataforma móvil CICD construida por Ionic.

Entonces, probablemente estén más familiarizados con Ionic o Capacitor que con AppFlow. Pero pueden aprender más sobre implementaciones móviles, construcción móvil, siguiéndome en Twitter o GitHub en Cecilia Creates. O no duden en contactarme en LinkedIn también en solo LinkedIn.com slash in slash my name.

Entonces, cuando hablamos de cross-platform, lo que estamos hablando específicamente son aplicaciones que construyes con una base de código, pero que implementas en cualquier lugar. Entonces, iOS, Android y también la web. Entonces, hay muchos frameworks que puedes usar para hacer esto. Si estás pensando en el tipo de ecosistema web y frameworks basados en la web, los que van a venir a la mente son React Native y luego Ionic emparejado con Capacitor. Pero también puedes usar herramientas como Flutter, que se basa en Dart, .NET MAUI o Kotlin Multiplatform. Pero la idea es que construyas una vez para implementar en cualquier lugar. Y esto no solo te da un proceso de desarrollo más rápido, sino una experiencia de desarrollador y user experience más consistente en todas las plataformas.

A menudo has visto algo donde, sabes, la versión iOS de la aplicación tiene una función que aún no está disponible en Android, o tal vez hay, sabes, ciertas aplicaciones que solo están en iOS. Y eso es porque normalmente puedes ver equipos separados trabajando en esas aplicaciones individualmente. Con cross-platform, borras ese tipo de problema. Pero cross-platform no está sin sus propios desafíos. Entonces, mientras los procesos de desarrollo son los mismos, los procesos de implementación no lo son. Tienes procesos de construcción, testing, e implementación muy, muy diferentes en la web, iOS y Android. Esto crea desafíos realmente específicos cuando se trata de testing estas aplicaciones, especialmente cuando estás testing las compilaciones nativas reales en dispositivos reales. Tienes casos de prueba específicos de la plataforma que también debes considerar. Entonces, incluso si escribes el código de la misma manera, interactuará con el dispositivo de manera diferente, y tienes que considerar eso. Y eso requiere cierta experiencia en cada plataforma. Entonces, si eres un desarrollador web y estás construyendo cross-platform por primera vez, y es la primera vez que estás lidiando con aplicaciones móviles, tienes que aprender los matices entre Android e iOS para poder probar eficazmente esas aplicaciones. Y testing es realmente importante para las aplicaciones móviles. Las implementaciones son de alto riesgo. Toman mucho más tiempo. Tienes que pasar por las tiendas de aplicaciones y lidiar con ese proceso de aprobación. Por lo tanto, las aplicaciones deben estar muy bien probadas antes de que se instalen en el dispositivo de un usuario. Los usuarios también son muy exigentes con sus aplicaciones móviles. Se encuentran con un error y desinstalan, o nunca lo usan de nuevo. Por lo tanto, es importante que puedas probar estas aplicaciones adecuadamente.

Entonces, en un esfuerzo por ayudar a abordar algunos de estos desafíos, hay mucho de lo que podríamos hablar, pero en el tiempo que tengo, me voy a centrar en estas áreas. Voy a hablar sobre los tipos de dispositivos, virtuales y reales, que tienes para testing tus aplicaciones. Voy a hablar sobre los tipos de compilación específicos para iOS y Android. También voy a hablar sobre cómo puedes distribuir versiones de prueba de tu aplicación a los probadores manuales. Sí, voy a hablar un poco sobre las pruebas manuales, lo prometo, pero es importante para móviles. Y luego también voy a hablar sobre cuándo y cómo aprovechar las pruebas automatizadas, tanto en Android como en iOS.

Entonces, comencemos con los dispositivos. Ahora, cuando hablo de dispositivos, me refiero literalmente al teléfono que probablemente tienes en tu bolsillo ahora mismo. Pero primero, hablemos de los dispositivos virtuales. Estos son dispositivos de software que replican un dispositivo real. Para Android, tienes emuladores. Para iOS, tienes simuladores. Hay un poco de diferencias técnicas. Son esencialmente lo mismo, pero como son plataformas diferentes, quieren tener cada una su propia versión especial de ello. Entonces, tienes emuladores y simuladores. Estos vienen preinstalados con Android Studio y Xcode. Entonces, si estás utilizando Android Studio y Xcode para desarrollar, ya tienes estos en tu máquina de desarrollo. Si no los tienes, por ejemplo, si no eres responsable de crear esas compilaciones nativas, entonces no tienes esos emuladores y simuladores. Eso puede dificultar un poco las cosas también. Se pueden utilizar para pruebas manuales o automatizadas. Entonces, si quieres simplemente abrir uno rápidamente, lanzar tu aplicación y hacer clic alrededor, puedes hacerlo, o también puedes vincularlos para pruebas automatizadas.

A continuación, tenemos dispositivos reales. Las pruebas en dispositivos reales son importantes porque proporcionan la mejor fidelidad de la user experience. Incluso en un emulador o un simulador, no puedes, por ejemplo, tomar una foto tan bien como lo harías con un dispositivo real. No puedes entender ciertas capacidades de carga o problemas de performance que puedes ver en un dispositivo real. También hay diferentes tipos de dispositivos a los que puede que no tengas acceso en un emulador o simulador que podrías obtener en un dispositivo real. Por lo tanto, es importante probar en dispositivos reales, pero hay mucha complejidad involucrada en ello. Así, para iOS, los dispositivos tienen que estar registrados para poder ejecutar el binario nativo en el dispositivo de la aplicación. Puedes hacer esto conectando el dispositivo a tu máquina de desarrollo. Para iOS o para Android, también puedes descargar e instalar el binario en el dispositivo.

Y de nuevo, puedes usar dispositivos reales, obviamente, para pruebas manuales o para pruebas automatizadas. Por lo tanto, puedes ejecutar pruebas automatizadas en dispositivos reales. Entonces, hablemos de compilaciones. Entonces, cuando pensamos en, ya sabes, compilaciones web, realmente tú decides cómo se ve esa compilación web. Por lo tanto, puedes tener una versión de prueba de tu aplicación web que llega, como, a un punto final de API diferente o tal vez vive en un entorno diferente. Pero en última instancia, tú controlas cómo se ve esa compilación web y qué entra en ella y cómo está configurada.

Para las plataformas móviles, Android e iOS, en realidad tienen tipos de compilación específicos que ejecutarás cuando crees el binario nativo compilado que se ejecutará en un dispositivo. Debido a esto, en realidad tienes que pensar en qué tipo de compilación necesitas hacer dependiendo de qué tipo de pruebas vas a poder hacer. Entonces, para Android, tienes depuración y lanzamiento. Para iOS, tienes compilaciones de simulador, que por supuesto se ejecutan en un simulador. Y luego tienes desarrollo, ad hoc, tienda de aplicaciones y empresa. Me gusta decir que iOS siempre va a ser dos veces más complicado que Android. Y entonces, verás un tema donde para iOS, tienes el doble de tipos de compilación, tienes el doble de credenciales de firma que necesitas usar para firmar tu aplicación, tienes el doble de programas de desarrolladores para los que tienes que registrarte y pagar. Y entonces, iOS siempre va a ser un poco más complicado.

Entonces, cuando piensas en tipos de compilación en el contexto de las pruebas, me gusta pensar en las compilaciones web como ideales si vas a poder hacer algunas pruebas basadas en navegador. Entonces, puedes hacer esto en un navegador web con vista de puerto móvil, o como vimos anteriormente, puedes usar Nightwatch para lanzar un navegador móvil real en un emulador. Esto es genial porque no se requiere firma de código ni hardware específico. Si estás ejecutando en un navegador, si estás ejecutando en un emulador o simulador, no necesariamente tienes que pasar por el proceso de firma. Si no has pasado por la firma de código antes, es crear un paquete firmado que verifica quién creó el paquete, que estaba autorizado para hacerlo, y que no fue alterado o modificado desde el momento en que fue creado. Las compilaciones requieren credenciales específicas que deben existir en la máquina que usas para crear la compilación. Por lo tanto, puede ser difícil simplemente crear una si no tienes acceso a esas credenciales. Por eso, las compilaciones web y las compilaciones de dispositivos virtuales son ideales para las pruebas, porque puedes crearlas por tu cuenta. Para Android, tenemos compilaciones de depuración, que también son ideales para las pruebas porque, de nuevo, no tienen que ser firmadas, y también son una versión no optimizada de la compilación. Entonces, si necesitas acceso al código subyacente, es más fácil identificar y depurar. Para iOS, tienes tus compilaciones de simulador para pruebas de dispositivos virtuales. Si quieres hacer pruebas internas de dispositivos reales, normalmente vas a usar una compilación de desarrollo o ad hoc. Y si te gustaría subir a TestFlight, vas a necesitar hacer una compilación de tienda de aplicaciones, que es un cierto tipo de compilación. Ahora, desarrollo, ad hoc, y tienda de aplicaciones sí requieren firma de código. Muy bien. Hablemos de la entrega de aplicaciones.

Entonces, cuando hablo de entrega, me refiero a cómo tus probadores manuales obtendrán tu versión actual de tu aplicación en su dispositivo para testing. Así que, las pruebas manuales siguen siendo un enfoque realmente amplio y algo necesario para las pruebas de aplicaciones móviles porque hay algunas cosas específicas que son difíciles de automatizar con dispositivos reales. Y esto me sorprendió. Vengo de un fondo de pruebas web, y estoy en el nivel de automatizar todas las cosas, ya sabes, nivel de testing. Así que me sorprendió cuánto se sigue haciendo pruebas manuales en el espacio de las aplicaciones móviles.

Esto requiere una gestión de dispositivos. Como dije, no solo tienes que registrar todos tus dispositivos para las compilaciones de iOS, sino que necesitas pensar en qué tipos de dispositivos necesitas probar. Entonces, ¿qué tipos de dispositivos están usando tus usuarios? ¿Cuál es la performance de esos dispositivos? ¿Hasta dónde quieres dar soporte? Entonces, si estás usando solo como testing en el último y más nuevo iPhone con las mejores, ya sabes, especificaciones y todo, esa puede no ser la misma experiencia que alguien que está en un teléfono antiguo que puedes conseguir en el supermercado, ya sabes, experiencia. Y entonces, la mayoría de las personas crearán una matriz de dispositivos de prueba que cubre los diferentes dispositivos que necesitan probar realmente. Entonces, hay muchas opciones para entregar esos binarios de aplicaciones a tus probadores manuales. Uno que veo mucho es en realidad solo la entrega manual. Y aquí es donde los probadores descargan e instalan los binarios ellos mismos. Entonces, generalmente hay un almacenamiento centralizado. Incluso he visto a alguien usar un Google Drive donde suben archivos APK o IPA, y luego se notifica a los probadores que hay un nuevo archivo disponible. Lo descargan, lo instalan en su dispositivo y comienzan a testing. Y esto puede ser difícil para rastrear versiones o saber cuándo están listas las nuevas versiones. Entonces, si tienes un almacenamiento centralizado de todas estas diferentes versiones, pero es solo un entorno y no necesariamente está utilizando ninguna herramienta específica, es posible que no sepas qué versiones ya se han descargado y probado. No es fácil rastrear comentarios o entender a qué commit está vinculada una versión específica. Por lo tanto, realmente recomiendo usar herramientas de entrega de plataforma. Entonces, estas son específicas para cada plataforma, por lo que tienes que configurarlas por separado para Android y para iOS. Para Android, tienes lo que se llama test tracks. Estos están integrados en Google Play. Y tienes pistas de testing internas, que te permiten distribuir hasta 100 probadores internos. Y luego puedes promover esa versión a través de los múltiples canales después de eso, que es la pista de testing alfa o cerrada, y finalmente, la pista de testing beta o abierta. En el lado de iOS, tienes lo que se llama TestFlight. ¿Quién aquí ha usado TestFlight antes o ha probado una aplicación en TestFlight? Bien, genial. Sí. Entonces, creo que esta es realmente la forma de seguir, ya sabes, por el lado de iOS. Te permite tener un grupo de testing interno así como testing externo. Entonces, en el lado de Android, esta es la pista de testing interna.

Básicamente puedes crear listas donde añades a tus probadores internos. Y luego, cada vez que añades una nueva versión subiendo el paquete de la aplicación, esta está disponible para esos probadores, y pueden rastrear y ver qué versión es a la que están conectados. De nuevo, en el lado de App Store Connect, puedes crear un grupo interno. Y esto es para, de nuevo, hasta 100 usuarios, y esas son personas que están asociadas con tu organización interna de App Store. Pero luego también puedes promover eso a TestFlight, que te permite acceder a 10,000 probadores externos. Sin embargo, tienes que pasar por la revisión de App Store antes de poder enviar para pruebas externas en TestFlight.

Hasta ahora, este ha sido un proceso bastante manual, incluso si utilizas la Google Play Store y las herramientas de App Store Connect. Así que, también hay algunas formas de automatizar la entrega a estos probadores sin tener que subir manualmente esos paquetes. Por lo tanto, hay herramientas de desarrollo para enviar automáticamente esos binarios a Google Play y App Store Connect. Y esto también permite un mejor seguimiento de las versiones de tu aplicación. Hay APIs de desarrollador de App Store. Hay herramientas de integración CICD. Hay una llamada Fastlane, que utiliza, como, una sintaxis similar a YAML para orquestar cosas como subir a TestFlight, cosas como crear tus compilaciones nativas, e incluso cosas como las pruebas. O puedes usar una plataforma móvil CICD, como Bitrise o AppFlow. Por ejemplo, lo que esto parece en AppFlow es que creas una automatización cada vez que hay un push a una rama específica de Git. Eso inicia una nueva compilación, y luego podemos desplegar eso directamente a tu destino de TestFlight. Y así, cada vez que tienes un push a tu rama principal, esto estará listo para tus probadores internos automáticamente, si tienes la entrega automática habilitada, o puedes enviarlo para revisión para pruebas externas. Bien. La parte divertida, las pruebas automatizadas. Así que, hablamos de pruebas automatizadas. Hay pruebas unitarias, de componentes y de integración basadas en el marco específico que estás utilizando. También puedes hacer pruebas específicas de plataforma, Espresso para Android y Xe-Test para iOS. Pero normalmente, si estás usando React Native o Capacitor, podrás utilizar las herramientas de pruebas que ya conoces. Puedes hacer pruebas basadas en navegador de compilaciones web o pruebas de extremo a extremo de compilaciones nativas en dispositivos virtuales o reales. Hay marcos como Appium, Maestro y Detox para hacer esto. Así que, pruebas automatizadas de dispositivos virtuales. Vas a utilizar esencialmente un simulador de iOS o una compilación de depuración de Android. De nuevo, estos están integrados en Xcode. Necesitas instalar la aplicación en tu simulador o emulador, y luego puedes ejecutar la prueba contra el dispositivo virtual.

Entonces, vamos a echar un vistazo a algún código. Este es un código de prueba de Appium Android. La prueba en sí es bastante sencilla. Realmente, vamos a acercarnos aquí. Solo estamos haciendo clic en algunas pestañas. Entonces, estamos abriendo la aplicación. Tiene tres pestañas en la parte inferior. Estamos haciendo clic para pasar a la segunda y tercera pestaña y asegurándonos de que funcionen.

Y entonces, lo que quería señalar aquí es la sección del controlador. Entonces, la sección del controlador es cómo configuramos realmente cómo se ejecuta esta prueba. Y eso va a estar basado en este objeto WD-ops aquí. Entonces, solo estamos ejecutando esto localmente contra un host de Appium que estamos ejecutando en nuestro sistema contra ese puerto. Y también estamos especificando un nombre de dispositivo de Android y la ubicación donde se encuentra el binario. Esto es importante porque entonces cuando inicio mi servidor de Appium y luego ejecuto Node-Android-Test.js, va a localizar esa aplicación, va a lanzar el emulador de Android. Va a tomar la ubicación de ese APK. Va a instalar eso y va a ejecutar la prueba contra él.

Entonces, ¿qué pasa si queremos ejecutar esto en un dispositivo real? Entonces, de nuevo, requiere algo de firma de código y registro de dispositivo para iOS. Pero puedes conectar un dispositivo a tu máquina de desarrollo, ejecutar lo mismo, pero especificar el dispositivo real en lugar del dispositivo virtual. O puedes usar algo como un servicio de cloud de dispositivos reales. Esto es mucho más intensivo en recursos, especialmente si necesitas gestionar todos estos dispositivos reales tú mismo o usar un servicio de cloud. Por lo tanto, es mejor para algo como pruebas de humo o cosas que requieren el hardware real específicamente. Entonces, vamos a echar un vistazo a un ejemplo de eso. Vamos a usar algo llamado SOS Labs. Hay muchas opciones. Solo usé SOS Labs porque tenía un plan gratuito. Principalmente, vas a ver principalmente soporte de Appium para estos servicios de cloud de dispositivos. Esperemos que veamos más soporte en el futuro de otros frameworks también. El proceso es que vas a necesitar crear una compilación de prueba, subir esa compilación de prueba al servicio de cloud. Configuras tu prueba con el nombre del archivo de compilación y el tipo de dispositivo y pones en marcha tu servidor de pruebas para ejecutarlo. Entonces, vamos a echar un vistazo al código.

Como dije, lo primero que tienes que hacer es subir la aplicación de Android o iOS. Puedes hacerlo subiéndola en la consola de SOS Labs o también puedes usar cURL.

Entonces, aquí está la misma prueba que estábamos viendo antes. Sin embargo, la diferencia es que el controlador va a ser un poco diferente. En cambio, estamos pasando nuestro usuario y clave de SOS Labs, así como estableciendo el nombre del host y el puerto para usar SOS Labs para ejecutar la prueba. Todavía estamos pasando el objeto de capacidades. Echemos un vistazo a eso.

De nuevo, todavía estamos pasando una ubicación de archivo. Sin embargo, en este caso, es en realidad un nombre de archivo en el servidor de SOS Labs porque hemos subido el archivo allí y le estamos diciendo, oye, SOS Labs, usa este nombre de archivo e instálalo en el dispositivo Samsung Galaxy S9 Free y ejecuta la prueba contra eso. También estamos pasando un ID de compilación y el nombre de la prueba. Esto es importante porque significa que nuestro registro de prueba estará conectado al ID de compilación que también estará conectado a un nombre de prueba por lo que podemos rastrear fácilmente si algo sale mal la compilación real que inició esa prueba.

A lo que termina pareciéndose es que después de que se ejecuta la prueba, ves esto en tu panel de control de SOS Labs. Puedes ver la video grabación de la prueba. Está haciendo clic en las pestañas. Como probablemente notaste, tarda mucho tiempo en iniciarse. Eso es porque tiene que instalar tu aplicación en el dispositivo antes de que pueda comenzar a ejecutar la prueba. Como dije, este es un proceso intensivo en recursos. Estás usando un dispositivo real, los dispositivos cuestan dinero. También lleva tiempo ejecutar estas pruebas porque tienes que instalarlas antes de cada una. Realmente considera cuáles son tus casos de prueba y casos de uso para esto.

Ahora, de nuevo, esto sigue siendo un poco un proceso manual. Estás subiendo el binario de la aplicación. Estás lanzando la prueba desde tu consola. ¿Y si quieres hacer esto en CICD? El proceso sigue siendo el mismo. Vas a crear tu compilación de prueba. Vas a subir esa compilación de prueba al servicio de cloud. Vas a configurar tu prueba con el nombre del archivo de compilación y el tipo de dispositivo. Vas a iniciar tu servidor de pruebas y ejecutar la prueba. Esta vez, lo vamos a hacer en una GitHub Action. Este es un flujo de trabajo de GitHub Action para hacer una prueba de Sauce Labs en Android.

Estoy configurando algunas variables de entorno. Mi usuario de Sauce Labs, mi clave de Sauce Labs y el nombre del archivo APK. Aún mejor, ahora estoy vinculando eso al SHA de GitHub. Ahora sé con qué commit se creó esa compilación, por lo que puedo rastrearlo hasta el commit real que lanzó esta compilación.

El siguiente paso, por supuesto, es crear una compilación de prueba. Estoy usando el Ionic Cloud CLI para hacer esto. Realmente, podrías hacer esto en la máquina CICD que estás utilizando. Tendrás que mantener la pila de compilación para crear las compilaciones de Android o iOS. Si estás haciendo compilaciones de iOS, vas a necesitar hardware de Mac. Si estás usando Ionic Cloud o App Flow, puedes usar sus credenciales y su infraestructura. Ellos manejan las credenciales de firma por ti. La parte importante a tener en cuenta aquí es que estamos nombrando el APK igual que nuestro SHA de GitHub, esa variable de entorno del nombre del archivo APK. Esto mantiene todo consistente y organizado.

De nuevo, el siguiente paso es subir el APK a Sauce Labs. Estoy ejecutando el comando curl, pasando mi usuario y clave. De nuevo, como dije, la parte importante es que lo estoy nombrando con ese nombre de archivo APK. Esto va a conectar el nombre del archivo con el SHA de GitHub, con la compilación. Todo es realmente consistente y fácil de usar.

Por último, pero no menos importante, voy a ejecutar la prueba. Aquí es donde inicio Appium. Así que inicio mi servidor Appium, y luego estoy ejecutando mi archivo node appium slash Sauce Labs Android test.js. Estoy pasando esas variables de entorno de mi usuario, mi clave, el ID de la compilación, que corresponde a mi SHA, y el nombre del archivo para localizar esa prueba.

Un par de mejores prácticas rápidas a tener en cuenta antes de terminar. Aprovecha las pruebas web tanto como puedas, ya sea en un navegador web real o en un navegador móvil. Cuantos más casos de uso puedas cubrir con pruebas web, menos intensivas en recursos serán tus pruebas, y también podrás identificar problemas antes antes de llegar a pruebas de extremo a extremo más nativas. Usa herramientas específicas para móviles o ten un miembro del equipo dedicado para móviles. Vas a necesitar entender realmente esas sutilezas entre las plataformas, y alguien en el equipo debería estar preparado para manejar eso si no vas a usar herramientas específicas para móviles. Y también automatiza de manera incremental. No empieces de golpe tratando de automatizar todo tu código de prueba basado en dispositivos reales. Identifica dónde están los cuellos de botella y cuáles son los caminos críticos y empieza a automatizar allí.

Muy bien, muchas gracias. Puedes obtener todo el Flujo de Trabajo de Acción de GitHub utilizando el código QR que hay allí. Y no dudes en visitar useappflow.com si tienes alguna pregunta. Muchas gracias por tu charla. Realmente lo aprecio también. Y lo que me encanta es que fue, y obtienes estas charlas donde son algo agnósticas al marco de trabajo. Así que hablaste sobre las ideas y los procesos de pensamiento detrás de esto. Y hay un montón de diferentes tipos de frameworks que alguien podría usar. ¿Y hay alguna consideración específica del marco de trabajo, tal vez, que hayas visto donde has visto a otras personas tratar de implementar estos procesos en el mundo real? Sí, así que dos cosas que vienen a la mente específicamente. Una es que si estás utilizando un marco de trabajo basado en la web, vas a poder aprovechar muchas de las herramientas web tooling. Muchos de los frameworks que no se basan en tecnologías web, tienen su propio ecosistema específico. Así que no vas a poder usar paquetes específicos que podrías usar para, como, un proyecto web general o algunas de las herramientas web a las que estás acostumbrado. Así que sólo crea un poco más de separación. La otra cosa a tener en cuenta es que en términos de los frameworks, ya sabes, las diferencias que pueden ocurrir son el aspecto de configuración. Así que hay diferentes formas de configurar partes específicas de iOS y Android de tu aplicación dependiendo del marco de trabajo que utilices. Y algunos de ellos pueden ser realmente complicados. Tienes que entrar realmente en los archivos Swift y editarlos tú mismo. Así que también tomaría eso en consideración, también. Clásico. Sólo necesitaba asegurarme de que teníamos una respuesta de que depende, más o menos, en el escenario antes de comenzar. Muy bien, gracias también.

Y aquellos de ustedes que están haciendo preguntas, por favor sigan haciendo esas preguntas. Voy a saltar con estas preguntas de la audiencia. La primera es, ¿cómo podemos automatizar el tipo de compilación PWA? ¿Esto cubre desde sólo la prueba de compilación web testing? Sí, así que es esencialmente como una compilación web. Hay algunas configuraciones que necesitas hacer para crear esa PWA. Por ejemplo, si tiene alguna acción que se lleva a cabo cuando la estás guardando en la pantalla de inicio, es posible que quieras probar esas por separado para asegurarte de que funcionan. En su mayoría, simplemente instalarás el paquete PWA que se utiliza para el marco de trabajo con el que estás construyendo, y luego puedes seguir desde allí. En realidad, soy un gran fan de las PWA, y me alegra ver que están obteniendo más apoyo, y que Apple e iOS están yendo en esa dirección y nos permiten aprovechar más las PWA. Pero sí, esa es una opción realmente genial. Y en esa nota, en realidad, una de las cosas que le pregunto a la gente muchas veces es que dicen, oh, quiero construir una aplicación móvil para esto.

Y digo, ¿realmente necesitas una aplicación móvil? Porque una vez que estás en las tiendas de aplicaciones y tienes que empezar a pasar por ese proceso, se vuelve mucho más complicado. También tienes que hacer un mantenimiento constante para asegurarte de que siempre estás al día con los últimos standards. Así que muchas veces digo, si puedes arreglártelas con la web móvil o con PWA, quizás vayas por el camino fácil y no te lo pongas demasiado difícil.

Por supuesto. Y también, debería hacer esto más a menudo, pero solo para las personas que tal vez no estén familiarizadas con las siglas, PWA. Sí. Aplicación Web Progresiva. Así que esencialmente es una aplicación web que puedes guardar en tu página de inicio de la misma manera que lo harías con una aplicación regular. También tiene unas capacidades fuera de línea realmente geniales. Eso es algo que te pierdes con las web apps móviles. Y eso es algo que básicamente imita la aplicación móvil sin interactuar con la capa nativa.

Definitivamente. Muy bien. Así que pasemos a otra pregunta. Esta es un poco específica de tooling. Y pidiendo tu opinión, porque estoy seguro de que has usado un par de diferentes herramientas por ahí. Entonces, ¿cuál es tu opinión sobre Expo y Expo Go como parte de ese proceso de desarrollo?

Sí. He usado Expo y Expo Go. Creo que es una gran developer experience para poner en marcha una aplicación. Es super rápido, super fácil. Incluso diría que para muchos casos de uso si vas a usar React Native, usa Expo. Creo que simplemente usa Expo. Lo he hecho de ambas maneras, con y sin. Creo que obviamente, voy a usar Depende de nuevo. El tipo de aplicación que estás construyendo con el marco que eliges dependerá de lo que sea tu proyecto y cómo sea tu equipo también. Estoy en Ionic, y usamos tooling basado en web. Y todo es específicamente web. Así que usas React, Angular, o Vue. Así que si tienes un equipo web existente que ya está construyendo con esas herramientas, y quieren construir para móvil, esa puede ser una transición realmente fácil. Pero si estás buscando algo que quizás estás construyendo desde cero y estás buscando algo un poco diferente, Expo y Expo Go, creo, también son herramientas realmente geniales.

Y creo que esto solo va a decirte, cuando estás buscando probar algo nuevo, hay una gama de diferentes herramientas por ahí. No solo escuchas una herramienta y dices, esa es la herramienta que voy a usar, ¿verdad? Exactamente. Y luego tenemos otra, que es más acerca de simplemente enfoques. Entonces, ¿qué enfoque recomendarías para probar las web apps que se ejecutan en navegadores móviles y de escritorio? Y usando tal vez herramientas para hacer emulación o usando dispositivos reales, ¿entonces algunas de esas herramientas para eso?

Sí. Lo bueno de las aplicaciones cross-platform es que una de esas plataformas es la web. Y siempre empezaré con la web primero si estoy construyendo cross-platform que se ejecuta en la web porque va a ser la menos intensiva en recursos. También puedo usar las herramientas que ya conozco y amo. La razón por la que la prueba de Appium fue muy simple es porque no estoy tan familiarizado con la escritura de pruebas de Appium ¿verdad? Y preferiría escribir pruebas de Cypress si puedo. Entonces, si puedo cubrir el 80 al 90% de mis casos de uso usando pruebas basadas en navegador, voy a hacer eso. Y luego buscando esos casos específicos de plataforma donde necesito aprovechar una herramienta de pruebas nativas reales de extremo a extremo. Lo bueno es que estamos viendo cada vez más tooling. Incluso hay cosas como Maestro. Hablamos de Nightwatch antes que puede usar algunos de los paradigmas más que estás acostumbrado con la web y luego aún ejecutarlo en un emulador o simulador para hacer algunas pruebas de dispositivo automatizadas también. Me encanta eso también. Y de esa manera llegas a, especialmente cuando estás empezando, puedes enfocarte en probar la lógica de negocio con el ecosystem que tiene muchas herramientas disponibles. Y luego a medida que te vuelves más específico para apilar luego el dispositivo, luego cambiando las herramientas que usas en el camino también. Realmente me gusta eso. Y luego hemos hablado de quizás diferentes tipos de pruebas, pero específicamente pruebas de rendimiento en móviles. ¿Cómo automatizarías eso? Sí, entonces las pruebas de rendimiento son un tipo completamente diferente de bestia, diría. Es algo donde tiendo a enfocarme en las pruebas de usuario, pruebas de aceptación. Las pruebas de rendimiento, hay herramientas específicas para eso porque es realmente va a depender del dispositivo en el que estés. Y también va a depender de la conexión de red que tengas. Y hay formas de simular eso de la misma manera que puedes en un navegador, ¿verdad? donde puedes simular la conectividad, puedes simular diferentes dispositivos. Entonces es donde esa matriz de dispositivos realmente va a ser útil. Y normalmente puedes ejecutar una prueba, y eres capaz de registrar cuánto tiempo lleva hacer ciertas acciones en diferentes tipos de dispositivos. Y habrá cosas específicas de rendimiento que también puedes ejecutar. También hay muchos marcos de pruebas móviles realmente geniales que no se basan en código. Son plataformas que esencialmente ejecutarán esas pruebas, como crearán y ejecutarán esos tipos de pruebas de rendimiento para ti. E incluso simplemente lo generarán en base al binario. Realizarán algunas comprobaciones, y podrán validar. También puedes hacer cosas como optimizar en función del tamaño del paquete, y asegurarte de que eso va a ser consistente en términos de rendimiento para tu usuario final. Totalmente. No creo que tengamos suficiente tiempo para una pregunta más, así que lo voy a dejar aquí. Pero muchas gracias. Y si quieres hacer preguntas a Celia, siempre puedes ir a la sala de discusión de preguntas y respuestas aquí en persona. Y si estás en línea, dirígete a la pestaña de preguntas y respuestas en Discord para que puedas hacer tus preguntas allí, y ella también las atenderá. Demos un gran aplauso a Celia una vez más. Gracias.