Pruebas Efectivas con Detox

Rate this content
Bookmark

Así que has configurado Detox para probar tu aplicación React Native. ¡Buen trabajo! Pero aún no has terminado: todavía hay muchas preguntas que necesitas responder. ¿Cuántas pruebas escribes? ¿Cuándo y dónde las ejecutas? ¿Cómo te aseguras de que hay datos de prueba disponibles? ¿Qué haces con partes de tu aplicación que utilizan APIs móviles que son difíciles de automatizar? Podrías invertir mucho esfuerzo en estas cosas, ¿vale la pena?


En esta masterclass de tres horas abordaremos estas preguntas discutiendo cómo integrar Detox en tu flujo de trabajo de desarrollo. Saldrás con las habilidades e información que necesitas para hacer de las pruebas Detox una parte natural y productiva del desarrollo diario.


Tabla de contenidos:


- Decidir qué probar con Detox vs React Native Testing Library vs pruebas manuales

- Configuración de una capa de API falsa para pruebas

- Cómo hacer que Detox funcione en CI en GitHub Actions de forma gratuita

- Decidir cuánto de tu aplicación probar con Detox: una escala móvil

- Integración de Detox en tu flujo de trabajo de desarrollo local


Prerrequisitos


- Familiaridad con la construcción de aplicaciones con React Native

- Experiencia básica con Detox

- Configuración de la máquina: un entorno de desarrollo CLI de React Native en funcionamiento que incluye Xcode o Android Studio

159 min
25 Oct, 2023

AI Generated Video Summary

La masterclass cubrió temas como las pruebas con Detox, la falsificación de la capa de API y la determinación de la cobertura de las pruebas. Se enfatizó la importancia de equilibrar el realismo y la velocidad en las pruebas y los beneficios de ejecutar incluso pruebas mínimas. El ponente proporcionó ideas sobre cómo configurar backends simulados y usar módulos falsos para las pruebas. También se discutió la configuración de Detox para CI y el flujo de trabajo de desarrollo local.

1. Introducción a la Masterclass de Pruebas con Detox

Short description:

Gracias por unirse a la Masterclass Efectiva de Pruebas con Detox en React Advanced 2023. Cubriremos pruebas con Detox, falsificación de la capa API, cuánto probar, ejecución de Detox en servidores CI y flujo de trabajo de desarrollo local con Detox. Los requisitos previos incluyen experiencia con React Native y Detox, así como conocimiento de pruebas unitarias, de componentes y de extremo a extremo.

Genial. Muchas gracias a todos por unirse. Esta es la Masterclass Efectiva de Pruebas con Detox en React Advanced 2023. Hay una página de inicio de la masterclass aquí. También estará en el pie de página de todas las diapositivas para que puedas consultarlo en cualquier momento.

Primero que nada, quiero comenzar con una visión general de lo que vamos a hacer juntos durante las próximas tres horas. Vamos a hablar sobre qué tipo de cosas tiene sentido probar con Detox, y qué tipo de cosas podrías querer probar de otras maneras. Vamos a hablar sobre el enfoque de falsificar la capa API en tu aplicación React Native para facilitar las pruebas automatizadas, hablar sobre cuánto de tu aplicación probar con Detox, cuánto quizás es demasiado, quizás no vale la pena. Hablando sobre la ejecución de Detox en servidores de integración continua, muy importante para obtener los beneficios de las pruebas para verificar que tu aplicación sigue funcionando. Finalmente, algunas ideas sobre el flujo de trabajo de desarrollo local con Detox. ¿Cómo puedes integrarlo en tu trabajo y no hacer que sea solo una cosa de una sola vez? Eso es lo que vamos a hacer juntos.

Quiero dar las gracias a los organizadores de React Advanced por la oportunidad de dar esta masterclass. He realizado varias masterclasses a través de sus conferencias y realmente lo disfruto, Hemos pasado un buen rato juntos con la gente en línea. Así que, sí, muchas gracias por la oportunidad. Y espero que todos los que asistan y revisen la grabación más tarde se beneficien de ella.

Una breve nota sobre los requisitos previos. Así que esta masterclass está enfocada para las personas que ya tienen experiencia con React Native. Lo has usado un poco para crear algunos componentes, algunas pantallas. Un requisito previo es que tengas experiencia con Detox. Así que no vamos a presentar Detox aquí. Tengo otra masterclass donde lo he hecho antes. Pero si no has usado Detox, probablemente podrás seguir lo que está sucediendo en general. Solo recomendaría ir y ver una introducción a Detox o leer a través de la documentación de Detox para obtener una sensación más profunda de las características básicas de la misma. Y como verás en un minuto, tengo un sitio web que te guiará a través de algunas introducciones también a Detox. También, como requisito previo, recomendamos tener experiencia con diferentes tipos de pruebas, como pruebas unitarias, pruebas de componentes y pruebas de extremo a extremo. Si no lo has hecho, tendrás una idea de cómo encajan a medida que hablamos. Pero si aún no lo has hecho, te recomendaría que investigues estas cosas. Y aunque no hayas hecho todas estas pruebas en React Native, si las has hecho en otro lenguaje de programación o ecosistema, eso es suficiente conocimiento para que empieces. Pero de nuevo, si no has hecho esto antes, por favor, quédate para la masterclass. Creo que aún así sacarás mucho provecho de ella y podrás consultar más recursos después.

2. Sobre el Ponente y la Masterclass

Short description:

He sido un desarrollador de software profesional desde 2004, trabajando con varios lenguajes y frameworks. React y React Native han sido mi enfoque durante los últimos seis o siete años. He dado masterclasses y charlas sobre pruebas en conferencias como Chain React y React Advance. También mantengo un sitio web, reactnativetesting.io, que es un tutorial para aprender sobre pruebas unitarias, de componentes y de extremo a extremo en React Native.

Un poco sobre mí para darles un contexto de dónde vengo. He sido un desarrollador de software profesional desde 2004. Como probablemente puedan adivinar de ese marco de tiempo, he trabajado en un montón de diferentes lenguajes y frameworks y plataformas. Java, PHP, Ruby e iOS. También React y React Native han sido mi gran enfoque durante unos seis o siete años ahora. Algunas de las cosas que he tenido la oportunidad de hacer en las últimas dos conferencias de Chain React, una de las cuales fue en 2023 y la anterior fue antes de la pandemia en 2019. Tuve la oportunidad de dar una masterclass de testing de un día completo, incluyendo detox y la biblioteca de testing de React Native. En React Advance London el año pasado, di una masterclass sobre la otra principal herramienta de testing de React Native, la biblioteca de testing de React Native. Pueden consultar la grabación de eso en el sitio web de Git Nation si quieren aprender más sobre la biblioteca de testing de React Native. También en React Native EU, di una charla sobre desarrollo guiado por pruebas el año pasado. Y eso va a entrar en juego un poco más tarde, cerca del final de nuestra masterclass. También mantengo un sitio web llamado reactnativetesting.io. Este es un tutorial de una sola parada para aprender sobre pruebas unitarias, pruebas básicas, pruebas de componentes y pruebas de extremo a extremo en React Native. Así que si son nuevos en estas cosas o simplemente quieren un lugar que lo reúna todo, pueden echar un vistazo a reactnativetesting.io, es un sitio web gratuito porque me gusta saber cómo hacer esas cosas. Y pensé que lo compartiría con la gente también.

3. Introducción a las Capas de Pruebas en React Native

Short description:

Actualmente trabajo en una consultoría llamada TestDouble, donde mejoramos el software. Si estás construyendo una aplicación React Native y necesitas ayuda con las pruebas, nos encantaría ayudarte. Nuestra experiencia se encuentra en las pruebas de React Native y React. Visita nuestro sitio web para obtener más información. La página principal de la masterclass se encuentra en rnte.st/London23, donde puedes acceder a los recursos mencionados durante la masterclass. Tomaremos descansos durante la sesión de tres horas para preguntas y descanso. Las pruebas unitarias son un buen punto de partida para probar las diferentes capas de una aplicación React Native, incluyendo el código JavaScript y el código nativo.

Así que actualmente trabajo en una consultoría llamada TestDouble, Somos una empresa que mejora el software del mundo. Y la razón por la que puedo trabajar en cosas divertidas como esta masterclass al margen es que trabajo en un lugar que me da trabajo divertido para hacer y equilibrio entre la vida laboral y personal para que pueda hacer mis propias cosas también. Y eso me encanta. Así que si estás construyendo una aplicación React Native, como probablemente lo estés, si estás en esta masterclass, nos encantaría ayudarte, especialmente si estás experimentando problemas con las pruebas. No sólo hacemos cosas de pruebas, pero como puedes adivinar por el nombre, es una gran pasión nuestra. Y así que las pruebas de React Native, las pruebas de React son algo de lo que sabemos mucho. Y nos encantaría ayudar. Así que visita nuestro sitio web si podemos ayudarte allí. De nuevo, la conferencia, diría conferencia, pero digo que la página principal de la masterclass está en rnte.st barra London 23. Y eso está en el pie de página de todas las diapositivas. Así que a medida que avanzamos en la masterclass, puedes abrirlo en cualquier momento. Cualquier cosa que mencione en cuanto a recursos, artículos, videos está todo enlazado desde esa página. Y si me he olvidado de algo, actualizaré la página justo después de la masterclass para poner los enlaces allí. Así que no dudes en echarle un vistazo.

No necesitas tener ninguno de los repositorios funcionando localmente para esta masterclass. Esto va a ser más un enfoque de mostrar y contar, pero están disponibles. Así que puedes descargarlos, puedes ejecutarlos, puedes jugar con ellos. También puedes verlos en el sitio web. Muy bien. Oh, también otra cosa logística importante. Tomaremos algunos descansos durante las tres horas. Descansos biológicos, necesitas un snack o algo así. O si simplemente quieres un tiempo para repasar lo que hemos hecho en un cierto segmento y profundizar en ello. Así que veremos cómo va el tiempo y nos tomaremos un tiempo para descansar. También puede ser un buen momento para preguntas. Cuando estoy compartiendo pantalla, no puedo ver el chat de Zoom, pero cuando salgo de la pantalla compartida, lo siento, cuando estoy compartiendo las diapositivas, no puedo ver el chat de Zoom, pero cuando salgo regularmente para mirar el código juntos, podré ver el chat. Así que no dudes en hacer preguntas en el chat. No dudes en ayudaros mutuamente. Si alguien sabe la respuesta a una pregunta que se ha hecho, no dudes en ayudar a los demás en el chat. Muy bien, así que con eso, vamos a empezar con nuestro primer tema, que es qué tipo de cosas probar con detox y qué tipo de cosas probar con otras herramientas. Si no has interactuado conmigo antes, te darás cuenta durante esta masterclass. No soy muy, bueno, no lo sé. Tengo opiniones sobre estas cosas, pero trato de hacer espacio para, como, necesitas tomar tus propias decisiones. Como, no necesito prescribir a esta es exactamente la forma de hacer las cosas. Trato de compartir principios y compensaciones y darte un modelo mental para pensar en las pruebas. Y luego eres capaz de tomar tu proyecto en tu organización con tu equipo y pensar en lo que funciona para ti. Y a veces desearía que las pruebas fueran simples y directas y hubiera sólo una forma de hacerlo, pero he encontrado con las pruebas automatizadas en particular, hay muchas compensaciones, hay muchos pros y contras. Y así que siempre necesitas expresar uh para hacer juicios y así um cuando estoy hablando de qué tipo de cosas probar con detox aquí hablaremos de por qué y cómo podrías decidir probar más con detox versus probar más con otras herramientas um una nota que diré también no lo puse en una diapositiva maestro es otra herramienta de pruebas de extremo a extremo muy análoga a detox vamos a hablar de cómo encaja todo pronto pero si si te has unido a nuestra masterclass de detox pero en realidad usas maestro o estás pensando en usar Maestro en su lugar, mucho de lo que estamos hablando no es específico de Detox. Me estoy centrando en una herramienta porque es la que uso. Pero muchos de los principios sobre estas cosas se aplicarían igualmente bien a Maestro. Así que siéntete libre de hacer tus propias aplicaciones a medida que avanzamos juntos. Muy bien. Entonces, cuando pensamos en qué tipo de cosas probar con Detox y qué tipo de cosas no, realmente queremos pensar en qué tipos de pruebas hay. Y vamos a centrarnos en la arquitectura específica de React Native y ver cómo encajan las herramientas de pruebas. Aquí hay un diagrama de la pila para una aplicación típica, o quizás cualquier o casi cualquier aplicación React Native, y cómo trabajan juntas las piezas. Dependiendo de lo nuevo que seas en React Native, o de cuánto trabajes a nivel de JavaScript, algunas de estas cosas pueden ser nuevas para ti. Es una pila complicada, y no sé si hay grandes, perfectas, explicaciones ideales por ahí. Vamos a profundizar. En una aplicación React Native, en el nivel más bajo conceptualmente, tienes el hardware físico, tu teléfono iOS, tu teléfono Android. Esto podría aplicarse a otras plataformas en las que se ejecuta React Native, pero específicamente Detox se centra en las pruebas móviles, y por lo tanto nos centramos en las principales plataformas de React Native para esta masterclass. Y esto también cubriría los simuladores de iOS y los emuladores de Android. Están emulando el hardware, y por lo tanto esa es esa capa. Encima de eso se ejecuta el sistema operativo del dispositivo, iOS o Android. Y luego encima de eso, tienes código nativo ejecutándose en tu aplicación. Así que muchos de ustedes probablemente lo saben, pero en una aplicación React Native, es una aplicación iOS o Android, incluso si estás usando Expo también. Y así una aplicación nativa se compila. La mayoría de ese código nativo y muchas aplicaciones, todo el código nativo proviene del framework, tal vez de las bibliotecas de terceros también. Siento que voy a estornudar, así que eso podría venir en un segundo. Pido disculpas si es fuerte. Así que hay código nativo ejecutándose allí. Y si tienes bibliotecas de terceros, a veces esas implican código nativo, podrías escribir un poco de código nativo en tu aplicación React Native también. Así que esa es una capa que se ejecuta. Encima de eso está el código JavaScript. Código JavaScript del framework React Native, tu propio código JavaScript. Y he separado el ciclo de vida de React y JSX aquí arriba. Y tal vez esa sea una separación un poco extraña ahora que lo pienso, pero será útil más tarde cuando pensemos en las pruebas. Algunos códigos JavaScript son simplemente JavaScript que se ejecuta. Finalmente, hay un motor JavaScript, Hermes, que está ejecutando JavaScript. Pero específicamente, una vez que tu código entra en el ciclo de vida de React y está involucrado JSX, y tienes componentes, React está funcionando, y está haciendo que todas esas cosas sucedan. Y luego finalmente, cuando devuelves JSX a React Native, finalmente eso se convierte en UI nativa. Como probablemente sabes, React Native consiste en widgets de interfaz de usuario nativos, vistas, y textos, y mapas, y otras cosas así. Y así se está renderizando una interfaz de usuario nativa. Como, finalmente, iOS y Android obtienen widgets de interfaz de usuario nativos que suceden allí. Así que, esa es la pila de tu aplicación React Native, al menos una forma de dividirla. Así que, como piensas en estas, como, estas son todas muy diferentes. Y entonces, la pregunta viene, sabes, ¿cómo podemos probar estas capas? Y vamos a empezar desde la prueba más enfocada a las pruebas más generales. Y la razón por la que estoy exponiendo esto, sólo para hacer una pausa un segundo para decir eso, puedes decir, hey, esto se supone que es como una masterclass de detox más allá de lo básico. Estoy familiarizado con estas cosas. No necesito lo básico. Pero lo que he encontrado es que, sabes, estas herramientas de pruebas son geniales para empezar. No necesariamente necesitas pensar en todos estos detalles para usarlos. Pero cuando se trata de diseñar un enfoque de pruebas para una aplicación comercial de producción, sabes, tener estos fundamentos claramente en mente ayudará. Y verás exactamente por qué se aplican a una estrategia de pruebas en un momento. Entonces, ¿cómo podemos probar estas capas? Bueno, las pruebas unitarias es lo primero que viene a la mente. Puedes tener pruebas unitarias de JavaScript. Y diré también, probablemente estés usando TypeScript. Casi todo el ecosistema de React Native se ha pasado a TypeScript, lo cual es realmente genial. Estoy atrasado, pero finalmente empecé a usar TypeScript, no en el código de esta masterclass, pero profesionalmente. Así que cuando hablo de código JavaScript o pruebas unitarias de JavaScript, todo se aplica igualmente bien a TypeScript también. La compilación de TypeScript se encarga de eso.

4. Capas de Pruebas en React Native

Short description:

En esta parte, discutimos las diferentes capas de pruebas en React Native. Comenzamos con las pruebas unitarias de JavaScript para el código JavaScript puro que no depende de React. Luego, presentamos la biblioteca react-native-testing, que permite probar los componentes de React y React Native. A continuación, exploramos Detox y Maestro, que cubren más capas de la aplicación, incluyendo los widgets de la interfaz de usuario nativa. También mencionamos Appium, una herramienta de pruebas de extremo a extremo más antigua que funciona con aplicaciones nativas. Finalmente, discutimos la inclusión de pruebas manuales y la importancia de considerar el realismo frente a la confianza en la selección de pruebas.

Es en su mayoría sin problemas la mayor parte del tiempo en el mundo de React Native. Así que si estás usando TypeScript, todas estas cosas también se aplicarán a ti. Pero mis viejos prejuicios me harán seguir diciendo JavaScript todo el tiempo. Así que para tu código JavaScript que no es específicamente React, tienes pruebas unitarias de JavaScript. Estos términos como pruebas unitarias pueden ser utilizados de diferentes maneras. Pero lo que quiero decir aquí es que tienes algún código JavaScript puro que no depende de React. Y tienes algunas pruebas unitarias, probablemente escritas en Jest, que prueban ese código directamente. Tienes una función donde pasas argumentos y obtienes un valor de retorno. Y puedes probar que funciona como esperas. así que el código nativo también puede tener pruebas unitarias nativas si es código proporcionado por otros probablemente no vas a escribir pruebas para él pero sabes probablemente esperamos que tengan pruebas unitarias también y así esas pruebas unitarias pueden simplemente ejecutar esas funciones swift esas kotlin o supongo java o funciones de objective c así que las pruebas unitarias pueden probar estas funciones de trabajo muy enfocadas y recomendaría mucho en tu aplicación React Native escribir funciones JavaScript TypeScript que son muy enfocadas y no requieren el marco y luego puedes unit probarlas directamente, eso funciona muy bien.

En segundo lugar, añadamos la biblioteca react-native-testing. Así que he puesto esto un poco superpuesto, si piensas en que he alineado estos bloques con las partes de la pila que prueba. Así que la biblioteca react-native-testing, si la has usado en absoluto, sabes que te permite probar tus componentes de React, tus componentes de React Native. Te permite probar los hooks también, como que todo va junto porque eso es parte del ciclo de vida de React. Pero como parte de eso, también está cubriendo tu código JavaScript que se ejecuta como parte de tus componentes de React Native. Así que la biblioteca de pruebas de React Native se extiende a través de estas dos capas.

A continuación, tienes Detox y Maestro, y los menciono específicamente por su nombre porque hay otra herramienta de pruebas de extremo a extremo que vamos a ver en un segundo. Y puedes ver que Detox y Maestro cubren muchas más capas de tu aplicación. Así que están interactuando con tus widgets de interfaz de usuario nativa. Estás tocando e interactuando con ellos. Y en realidad, no creo que ninguna de estas herramientas requiera el uso de React Native. Puedes probar aplicaciones totalmente nativas también. Eso puede ser útil si tienes una aplicación nativa brownfield y has añadido React Native a ella. Ejecutan el ciclo de vida de React, así que no probarías los componentes directamente. Estás probando a través de la interfaz de usuario nativa. Pero está ejecutando el ciclo de vida de React, ejecuta tu código JavaScript. Ejecuta el código nativo bajo el capó que hace que eso suceda. Y está ejecutando el verdadero sistema operativo del dispositivo. Así que, sabes, está ejecutando iOS y ejecutando Android. y lo puse cubriendo el hardware físico a la mitad. Y la razón es que hasta donde yo sé hace un par de semanas, Detox y Maestro ambos, funcionan en simuladores de iOS y emuladores de Android y funcionan en dispositivos Android físicos, pero aún no funcionan en dispositivos iOS físicos. Ninguno de ellos. El hecho de que ninguno de ellos lo haga probablemente significa que hay buenas razones arquitectónicas por las que eso es un desafío. Pero ambos, creo que han dicho que les gustaría. Así que les gustaría cubrir completamente el hardware físico allí, pero esa es una pequeña limitación.

Finalmente, tenemos Appium. Appium es una herramienta de pruebas de extremo a extremo más antigua que no es específica de React Native en absoluto. Simplemente funciona con aplicaciones nativas y cubre toda la pila. Funciona en cualquier hardware físico, hardware físico de iOS, hardware físico de Android, así como simuladores. Funciona a través de la interfaz de usuario nativa, por supuesto, porque es agnóstica a tu marco. No sabe ni le importa React Native. Simplemente dice, dame una aplicación y interactuaré con ella. De hecho, dice que puedes simplemente darme un iOS o Android en ejecución y yo interactuaré con él. Trabajé hace unos contratos con algunos probadores muy experimentados. Y mientras hablábamos de Appium en una aplicación React Native, me dieron algunas grandes ideas que, así que Appium se ejecuta a través de algunas tecnologías web. Olvido si es WebDriver. Creo que es WebDriver Selenium. Y entonces hay un poco de desconexión. Como que las tecnologías que está usando no están tan directamente relacionadas con React Native y con lo nativo. Bueno, no directamente nativo, pero no el desarrollo nativo. Hay algunos otros aspectos en cuanto a la escama también. Y así Appium puede tender a ser un mejor ajuste para los probadores profesionales de automation, en lugar de, ya sabes, si eres un desarrollador y estoy hablando como un desarrollador, podría haber puesto eso en los prerrequisitos. Esto es un poco más enfocado en el desarrollador en esta masterclass hoy. los desarrolladores, queremos pruebas que podamos ejecutar localmente, y queremos pruebas que van a ejecutar en servidores de integración continua, y cada vez que fallan, eso nos dice que hay un bug en nuestro código. Appium, puede tender a ser un poco más inestable. Si vas a reactnativetesting.io, hablo sobre herramientas de pruebas de extremo a extremo y los compromisos entre Appium y luego Detox y Maestro,

5. Objetivos de Pruebas y Tipos de Pruebas

Short description:

Las pruebas de extremo a extremo son excelentes para probar la integración de JavaScript de primera y tercera parte y código nativo. Las pruebas manuales son las mejores para la suavidad de la animación, la experiencia del usuario y la integración con servicios de terceros. También es útil para probar conexiones externas del mundo real. Los objetivos de las pruebas incluyen el realismo, la velocidad y la fiabilidad. Equilibrar el realismo y la velocidad es crucial. Las pruebas manuales proporcionan una visión realista de la aplicación, mientras que las pruebas automatizadas son más rápidas. Las pruebas de extremo a extremo aseguran que el código JavaScript y nativo estén integrados correctamente y prueban el flujo completo del usuario. Los flujos de usuario se pueden ver en las pruebas para crear una tarea pendiente en una aplicación de código abierto.

Eso es realista, pero eso no te da confianza en tu aplicación. Eso puede causar que una prueba falle, y eso no significa que haya un error en tu aplicación. Es realista, pero no te da confianza en tu aplicación. Realismo como una caída de la conexión de red. Eso es realista, pero eso no te ayuda a confirmar. Si pruebas eso, si escribes una prueba para eso para estimular una caída de la conexión de red, eso puede darte confianza en tu aplicación. Pero si simplemente cae al azar, eso no te ayuda a saber que tu aplicación está funcionando mejor. Y aquí hay otro que va a surgir. Te lo mostraré en algunas de nuestras demostraciones que vienen. El teclado virtual aparece o desaparece cuando no lo esperas. Oh, en mi entorno de desarrollo local, el teclado virtual está apagado, pero en el servidor de integración continua, el teclado virtual está encendido, y eso es realista. Esa es una variación en tu aplicación, pero si causa que una prueba falle, eso no está aumentando tu confianza en tu aplicación. Estas son todas las razones con las pruebas de extremo a extremo que la gente dice, vaya, estas son tan inestables. No valen la pena. Simplemente renuncio a las pruebas por completo. Entonces, si dices, quiero confianza, y la confianza significa realismo, y solo estoy escribiendo pruebas de extremo a extremo, puedes encontrarte con estas cosas. y experimentar mucho dolor y mucho esfuerzo para mantener tus pruebas de extremo a extremo funcionando o intentar hacerlas funcionar, o puedes obtener fallos inestables todo el tiempo y puedes simplemente decidir, como algunos de mis antiguos compañeros de trabajo han decidido, las pruebas no son útiles. No añaden ningún valor. Solo es trabajo. Entonces, las pruebas son sobre confianza. En gran medida, tal vez haya otros factores también que no entran en juego para esta masterclass. Pero si quieres maximizar la confianza en tu aplicación, en realidad quieres aislarte de estas cosas realistas. Quieres aislarte de estas causas de fallo. Y así es como puedes pensar en eso. Una prueba estable menos realista te da más confianza que una prueba inestable realista. Ya sabes, esos añadiendo todo el realismo de la última diapositiva que vimos no está aumentando tu confianza. Y hay otro factor, una prueba menos realista que ejecutas todo el tiempo te da más confianza que una prueba realista que no ejecutas porque es lenta. Por lo tanto, la velocidad es un factor en las pruebas de extremo a extremo también, especialmente en móviles. Si simplemente lleva mucho tiempo ejecutar, como tal vez eso se ejecuta durante la noche, o tal vez lo ejecutas antes de un lanzamiento. Pero ya sabes, no estás obteniendo la retroalimentación, no obtienes la retroalimentación a medida que estás escribiendo tu código y cambiando la aplicación y refactorizando moviendo cosas, no estás obteniendo la confianza de que todavía está funcionando. Y en realidad, esto lo hace más difícil más tarde, si esperas mucho tiempo, si esperas hasta el final hasta el lanzamiento para ejecutar las pruebas de extremo a extremo, y ahora descubres, oh, un montón de cosas han fallado. Oh, sí, eso tiene sentido. He cambiado un montón de cosas en la aplicación. Bueno, ahora necesito empezar a arreglar estas pruebas de extremo a extremo. Eso puede ser mucho trabajo antes del lanzamiento. Y de nuevo, ahora has llegado al punto en que el ciclo de retroalimentación es tan largo, las pruebas no te están dando valor. Se han convertido en solo trabajo para ti, solo costo sin beneficio. Así que puedes obtener más confianza cuando hay una prueba que ejecutas todo el tiempo porque se ejecuta bastante rápido y es bastante fácil de ejecutar. Y eso va a entrar en los compromisos de cómo eliges diferentes enfoques de prueba también. Entonces hablemos de los objetivos de prueba que podrías tener para diseñar tu suite de pruebas y diseñar tu enfoque de prueba. Entonces un objetivo es el realismo. Eso es un objetivo. No es el único objetivo, pero es un factor. Si tus pruebas están totalmente divorciadas de la realidad, no va a ayudar mucho. Entonces, uno de los beneficios que puedes obtener de las pruebas es cuando son más realistas. Eso es útil en equilibrio. Otro objetivo de prueba es la velocidad. Entonces, Entonces, ya sabes, las pruebas más rápidas son mejores que las pruebas más lentas. Y eso es algo que también quieres tener en cuenta. Y quieres equilibrar o encontrar formas de obtener los beneficios del realismo y la velocidad. También la fiabilidad. Ya sabes, así que quieres obtener una prueba cuando una prueba falla. Quieres que eso generalmente sea porque hay un error en tu aplicación o has cambiado la funcionalidad y la prueba ya no coincide con ella. Realmente no quieres que las pruebas fallen debido a la inestabilidad, porque simplemente algo que no puedes controlar sucede. Eso es un costo. Eso no te está ayudando. Entonces, los objetivos de prueba de realismo, velocidad y fiabilidad. Veamos los posibles tipos de pruebas en nuestra caja de herramientas que vimos antes y veamos cómo nos pueden ayudar a alcanzar estos objetivos de diferentes maneras. Entonces, primero las pruebas manuales, comencemos por ahí. ¿Cómo ayudan las pruebas manuales y para qué son buenas? Suavidad de la animación. Esto es algo que los desarrolladores de móviles nativos me ayudaron a entender cuando pasé de la web al móvil, que en el móvil hay una fuerte expectativa de que la animación sea suave. Cualquier tipo de jank en la animación no es una gran experiencia. Y así, para aplicaciones de nivel profesional, quieres esa suavidad en la animación. Y eso es más fácil de ver en las pruebas manuales donde eres una persona probándolo, y miras y prestas atención para ver si la animación es janky. También la experiencia del usuario, simplemente pensando como, okay, hey, la aplicación está escrita de la manera que planeamos, pero ¿es realmente utilizable por una persona? ¿Tus dedos tienen problemas para llegar a partes de la pantalla? ¿Tienes que hacer movimientos incómodos para ir a diferentes partes de la aplicación? Entonces, realmente estás probando, ¿ha sido diseñada la aplicación de una manera que es útil? Las pruebas automatizadas realmente no pueden ayudar con eso, pero las pruebas manuales sí. Y este es parte del valor de ti, simplemente como desarrollador, o tu negocio, probándolo manualmente pensándolo, obteniendo pruebas de usuarios reales, así como profesionales de QA. Ellos pueden proporcionar estos beneficios. También, la integración con servicios de terceros. Me encanta contar la historia de un cliente para el que trabajé que era una cadena de comida rápida. Y así hablamos y bromeamos, pero era en serio, ¿qué son las pruebas de extremo a extremo? Las pruebas de extremo a extremo para ellos eran más que simplemente golpear el servidor del otro lado. La prueba es cuando llego a la ventana del drive-through, ¿recibo una bolsa de comida? Eso son pruebas de extremo a extremo. Y mientras estábamos construyendo, uno de mis compañeros de trabajo estaba construyendo la integración del servicio de entrega. La prueba de extremo a extremo era, ya sabes, ¿llega DoorDash con mi comida? Eso son pruebas de extremo a extremo. Y así las pruebas manuales son las mejores para eso. Sería difícil automatizar esas cosas a menos que tuvieras un robot o algo así. Quiero decir, incluso algo tan simple como recibos de tarjeta de crédito impresa si estás trabajando en un sistema que se integra de esa manera, probando contra una tarjeta de crédito física real que está siendo escaneada. Entonces las pruebas manuales pueden ser las mejores para integrar, bueno, dije servicios de terceros aquí, pero también cosas externas del mundo real a las que te estás conectando. Entonces las pruebas manuales juegan un papel allí. Hablar sobre realismo. Ahí tienes algo de realismo. ¿Recibo comida real que tiene calorías que puedo usar para vivir? Bueno, ¿qué tal las pruebas de extremo a extremo? He mostrado Detox y Maestro aquí, Pero Appian también caería en esta categoría. Las pruebas de extremo a extremo son geniales para probar la integración de JavaScript de primera y tercera parte y código nativo. Otro cliente en el que estuve, el mapa era una parte clave de lo que estábamos haciendo. Era un tercero, creo que Mapbox era el nombre del marco de mapeo. Y eso era todo en código nativo. Y así quieres saber, ¿está funcionando ese código nativo? ¿Está funcionando el mapa y me lleva a donde quiero ir? ¿Y se ve bien el mapa? Y así, si quieres probar a través de eso que tu código JavaScript está ejecutando código nativo correctamente. Las pruebas de extremo a extremo añaden mucho valor allí. También, ¿puede el usuario hacer lo que quiere hacer? Las pruebas de extremo a extremo prueban un flujo completo. Así que realmente escribes los pasos de como, primero hago esto, y luego eso, y luego la otra cosa. Cuando vemos pruebas en mi aplicación de código abierto

6. Capas de Pruebas y la Pirámide de Pruebas

Short description:

Las pruebas de extremo a extremo te ayudan a ver si hay pasos tediosos para un usuario o si algo se rompe. Puede verificar lo que genera dinero en tu aplicación y darte fallos tempranos. Las pruebas de componentes cubren eficazmente las ramas lógicas en el código de la interfaz de usuario, mientras que las pruebas unitarias cubren las ramas lógicas en el código no relacionado con la interfaz de usuario. Cuanto más realista sea la prueba, más esfuerzo se necesita para escribirla y mantenerla. La pirámide de pruebas combina pruebas realistas y menos realistas para obtener combinaciones óptimas. Se recomiendan las pruebas manuales, seguidas de las pruebas de extremo a extremo.

más tarde, vamos a ver los flujos de usuario a medida que crean una tarea pendiente. Es una aplicación de tareas pendientes, y las mueven a través de un progreso que podrían pasar de manera realista. Entonces las pruebas de extremo a extremo testing realmente te permiten y te obligan a recorrer todo ese camino, pero te ayuda a ver, ¿hay pasos tediosos para un usuario o algo se rompe? Porque cuando pasan por ese flujo, debido a la secuencia de este. Además, ¿puede la aplicación generar dinero? Esto es bueno para las pruebas de extremo a extremo porque puedes enfocarte en, bueno, ¿cuáles son las cosas que realmente generan dinero en mi aplicación? ¿Es completar una compra? ¿Es crear una suscripción? ¿Qué genera el dinero? Y entonces si vas a probar algo, si solo vas a probar una cosa en tu aplicación, testing lo que genera dinero para la empresa es bastante importante. Y entonces las pruebas de extremo a extremo realmente pueden verificar eso de una buena manera y darte un fallo temprano si eso no funciona.

A continuación, las pruebas de componentes, bajando un poco al nivel más bajo. ¿Puede esto agregar algo a nuestra caja de herramientas de testing? Primero, las pruebas de componentes son excelentes para cubrir completamente las ramas lógicas en el código de la interfaz de usuario. ¿Qué pasa con un estado de carga? ¿Qué pasa con un estado de error? ¿Qué pasa con los 10 tipos diferentes de mensajes de error que pueden venir del servidor? ¿Se muestran todos correctamente? Algunos de ellos se muestran en línea. Algunos de ellos son un pop-up. Algunos de ellos te redirigen a otra pantalla. ¿Estás cubriendo todos esos? Esas cosas pueden ser cubiertas en las pruebas de extremo a extremo, pero pueden ser lentas. Y también puede ser más difícil simular las diferentes respuestas para esos 10 mensajes de error diferentes. Y entonces las pruebas de componentes pueden ser realmente efectivas para cubrir completamente las ramas lógicas. No recomendaría, y la mayoría de los probadores experimentados no recomendarían, tratar de cubrir cada rama lógica en tu aplicación en una prueba de extremo a extremo. Pero hay mucho valor en cubrir cada rama. E incluso si no lo haces en cada componente, al menos en algunos de los principales en tu aplicación, puedes cubrir cada rama lógica en el código de la interfaz de usuario con pruebas de componentes. Y el código de la interfaz de usuario tiene tantos estados diferentes. Hubo una gran charla en la última React Advanced London sobre eso y cómo esos pueden multiplicarse indefinidamente. Y puedes cubrir eso de manera efectiva con pruebas de componentes.

Las pruebas unitarias, el beneficio es similar. Puedes cubrir completamente las ramas lógicas en el código no relacionado con la interfaz de usuario. Así que el código que formatea algo, el código que hace una solicitud a un servidor. Puedes cubrir completamente eso en las pruebas unitarias para que puedas estar seguro de que cada pieza funciona como esperas. Y eso añade exhaustividad, así como esas pruebas de componentes y esas pruebas unitarias son mucho más rápidas para las cosas para las que pueden ser utilizadas. Entonces, a medida que avanzamos hacia la combinación de estos, aquí hay un principio importante. Cuanto más realista sea la prueba, más esfuerzo se necesita para escribirla y mantenerla. Y esto puede no ser obvio. De hecho, escribí esto al principio. Y cuando volví a ello un mes o dos después, me pregunté, espera, ¿estoy seguro? ¿Cuál es el razonamiento para eso? Así que hablemos de eso. Entonces podrías decir, oh, bueno, ya sabes, y a veces la gente se siente atraída por las pruebas de extremo a extremo porque es como, oh, es menos esfuerzo para escribir. No necesito dividir mi código. No necesito reorganizarlo ni nada. Solo puedo escribir lo que haría el usuario. Bueno, eso es un poco fácil. Pero con el tiempo, hay más esfuerzo para esas pruebas de extremo a extremo. Y aquí está el por qué. Así que cada vez que cambias un flujo de usuario en tu aplicación o cada vez que cambias la estructura de data, eso puede romper muchas pruebas. Pensando en ese servicio de comida rápida, el menú del restaurante era una parte clave de la aplicación. Y esa era una estructura de data muy complicada. Entonces, a medida que evolucionaban esa estructura de data, eso podría romper todas las pruebas de extremo a extremo en nuestra aplicación, porque todas ellas usaban prácticamente el menú. También cambiamos el flujo de usuario. Añadimos pasos a medida que empezamos a implementar. esto es en realidad durante la pandemia, empezamos a implementar la recogida en la acera en lugar de conducir a través. Y entonces no teníamos en el restaurante en ese momento, pero luego lo añadimos. Hablar sobre una fase interesante de la historia. Y entonces eso estaba cambiando los flujos de usuario. Eso estaba añadiendo pasos. Y todas nuestras pruebas de pago se romperían hasta que las actualizáramos. Así que eso puede ser mucho trabajo. Eso es mucho mantenimiento para estas pruebas de extremo a extremo porque se ejecutan a través de toda tu aplicación. Ahora puedes evitar esto reutilizando el código de prueba. Así que solo tienes que cambiarlo en un lugar. Y los probadores de automatización profesionales experimentados hacen esto en sus suites de pruebas, como Appium, por ejemplo. Es como, no, escribes varias capas para que puedas decir, hey, inicia sesión. Y entonces, oh, aquí está la implementación de cómo iniciar sesión. Así que si el inicio de sesión cambia alguna vez, solo lo cambiamos en un lugar. Y así eso ayuda. Pero es mucho de esfuerzo para design y configurar la reutilización de tu código de prueba de una manera que funcione. Y la forma en que lo configuras inicialmente puede no ser la forma que realmente funciona con el tiempo. Ooh, estoy haciendo eco de tu micrófono. Déjame, ¿qué está pasando? Bueno, creo que está mejor ahora. Genial. Sí, así que eso es mantenimiento también, para configurar tu suite de pruebas de una manera que sea reutilizable. Así que solo porque estas pruebas de extremo a extremo se están ejecutando a través de tanto código, hay esfuerzo para escribirlas y mantenerlas significativamente. Y las mejoras en las tooling en el mundo de extremo a extremo ayudan con eso. Una de las razones por las que la gente ama maestro es que hay algunas cosas que lo hacen más simple y fácil que detox en algunos aspectos. Pero incluso la última tooling, como he visto las pruebas de extremo a extremo a lo largo d

7. Fomentando Pruebas con Detox y Libro Recomendado

Short description:

Fomento la realización de pruebas con Detox, pero no intentes cubrir todo. Realiza más pruebas de componentes y pruebas de JavaScript/TypeScript puro. Estructura tu aplicación de esta manera para beneficiarte de las fortalezas de cada tipo de prueba. Recomiendo el libro 'X Unit Test Patterns' de Gerard Mazaros para una base sólida en la teoría de pruebas.

Voy a fomentar la realización de algunas pruebas con Detox. Realiza algunas, pero no intentes cubrir todo en tu aplicación. Realiza más pruebas de componentes e incluso más pruebas de JavaScript puro, TypeScript puro. Si puedes estructurar tu aplicación de esta manera, vas a obtener el máximo beneficio y todos estos tipos de testing trabajarán juntos y se complementarán entre sí para beneficiarse de las fortalezas de los demás.

Y entonces vamos a ver un poco más cómo esto se desarrolla a lo largo de la masterclass. Quería aprovechar la oportunidad para recomendar un libro que se escribió hace un tiempo y que es muy útil en este sentido. Sabes, hemos estado hablando de la teoría del testing, pensando profundamente en cómo funcionan las pruebas y el tipo de compromisos que finalmente no son resolubles, pero que tienes que sopesar juntos.

Y entonces este libro, un libro clásico, X Unit Test Patterns de Gerard Mazaros. Creo que pronuncié bien ese nombre. Recomiendo mucho este libro. Puedes encontrarlo en Amazon o en plataformas de libros electrónicos. Fue escrito en 2007. Por supuesto, no aborda directamente React Native o React, pero te hará pensar en los compromisos de testing. Todos los tipos de compromisos de testing de los que he hablado aquí, provienen de este libro. Están descritos en este libro. Y así, si quieres obtener una base sólida en teoría que te acompañará indefinidamente en el futuro, para cualquier plataforma y enfoques de testing que vengan, este libro es genial. Y puede que llegues a conclusiones totalmente diferentes a las mías basándote en los principios de este libro. Y eso está totalmente bien. Así que recomiendo mucho que revises este libro si quieres profundizar en la teoría del testing.

8. Simulando Solicitudes de Servicio Web en Pruebas

Short description:

Hola, vamos a discutir la simulación de la solicitud de servicio web en pruebas. Conectar con un backend real en las pruebas de detox tiene ventajas, como el realismo y la prueba de todo el sistema. Sin embargo, también tiene desventajas, incluyendo la inestabilidad debido a la falta de fiabilidad de la red y la deriva de datos. Existen alternativas para probar el backend, como la simulación en diferentes capas y el uso de un servidor web local o un servidor web falso. Estas opciones proporcionan más estabilidad, simplicidad y control sobre los datos de prueba. El servidor web local ofrece beneficios para el realismo en las pruebas.

Hola, vamos a empezar con nuestro segundo segmento. Así que, para recapitular brevemente, al final de nuestra sección de teoría de pruebas, hablamos sobre la pirámide de pruebas. Y entonces hemos decidido por el bien del argumento juntos hoy que vamos a tener algunas pruebas de extremo a extremo. Vamos a tener algunas pruebas de detox. No es todo. No son todas nuestras pruebas. Pero, sabes, no estamos escribiendo solo pruebas unitarias y no estamos escribiendo solo detox. Va a haber una mezcla. Pero OK, así que vamos a tener algunas pruebas de detox y seguimos adelante.

Bueno, como habrás descubierto al adentrarte en detox, una vez que superas los conceptos básicos de hola mundo, como puedo tocar, puedo escribir en un campo de texto bastante rápido, te encuentras con la necesidad de hacer algo con tu capa de API. Sabes, la mayoría de las aplicaciones móviles van a hablar con una API HTTP, una API GraphQL, Web Sockets o algo más. Estás hablando con un servidor en algún lugar. Entonces, ¿qué haces? ¿Cómo pruebas eso? Así que puedes conectar con un backend real en tus pruebas. Y eso es algo así como el predeterminado. Si simplemente ejecutas tu aplicación y la pruebas, va a conectar con un backend real. Y entonces hay algunas ventajas en eso. Es más realista. Eso te va a dar un sistema en el que tu todo el sistema funciona junto. Si el backend cambia algo en un cambio que rompe, y tu aplicación de front end se romperá. Y eso te dice algo real y útil. Y entonces puede parecer que, oh, si no estoy testing en el backend real, no estoy realmente testing mi aplicación. Tiene mucho sentido. Sin embargo, hay desventajas en conectar con el backend real en tu prueba de detox también. Inestabilidad debido a la falta de fiabilidad de la red. Tal vez esté en tu ordenador o tal vez esté en un servidor de CI o tal vez el servidor donde se ejecuta el backend. Tal vez estás conectando con un backend de pruebas o de staging que no es tan fiable o que a veces se cae por mantenimiento. o tal vez simplemente literalmente un fallo en la conexión a internet. Podría haber interrupciones en diferentes sistemas. Así que tal vez tu servidor backend funciona bien, pero tal vez un servicio de notificación se cae o tal vez un servicio de correo electrónico se cae o algo así. También puedes tener data a la deriva. Así que cuando te conectas al backend real, como hay usuarios con data y podrías decir, oh, aquí está el usuario de prueba para la prueba automatizada, no cambies ninguno de estos registros, pero la prueba automatizada cambió los registros. ¿Y qué pasa si alguien lo ejecuta localmente O qué pasa si alguien está manteniendo cosas y reinicia ese servidor? Así que eso es una dependencia del backend real. De nuevo, es realista, pero puede disminuir tu confianza porque algo está roto que no indica un bug en tu código, en tu código de React Native. También puede ser difícil con los backends reales configurar los datos de prueba. Sabes, quieres probar todos esos diferentes escenarios. ¿Qué pasa si la cuenta del usuario ha caducado? ¿Y qué pasa si han renovado? ¿Y qué pasa si no tienen registros? ¿Qué pasa si tienen un millón de registros? Todas estas cosas pueden ser difíciles de configurar. Y puede ser una presión contra ti testing a fondo, porque estás como, mis pruebas probablemente son suficientemente buenas, no necesito probar ese otro escenario, porque es simplemente tan difícil configurar esos datos de prueba. Así que hay una alternativa, en realidad hay un número de diferentes alternativas para qué hacer con el backend en tu testing. Y hay tantas alternativas que tuve que hacer un diagrama al respecto. Así que déjame mostrarte aquí.

Así que aquí está una muestra de stack, este es un stack diferente que está girado de una manera diferente, pensando en una aplicación típica que podrías tener. Así que a la izquierda aquí, tienes el resto de tu código de aplicación para tu aplicación de React Native. Ahora, digamos que tienes algún tipo de módulo JavaScript TypeScript que es tu cliente de API. Es solo un módulo. Es tu código que dice, aquí están mis cosas sobre cómo conectar con el backend. Y desde allí, vas a probablemente una biblioteca de terceros. Tal vez sea Axios, tal vez sea Apollo GraphQL o algo así. Pero algún tipo de código de terceros que está manejando la solicitud al servidor por ti. Y luego soporte subyacente para solicitudes, que puede ser HTTP o tal vez algo más. Diremos HTTP por el bien de este ejemplo, pero este es el soporte HTTP proporcionado por React Native y Node y por, bueno, supongo que no Node, bueno, lo que sea. React Native y el sistema operativo subyacente que hace solicitudes HTTP. Y finalmente, está pasando a un servidor web separado. Así que de nuevo, puedes estar usando diferentes tecnologías en tu aplicación, pero el concepto de estas capas es análogo, y así podrás seguir el hilo.

Así que hablemos de algunas opciones para simular la solicitud de servicio web, es decir, reemplazar las solicitudes reales a un servidor con algo más. Así que hay muchas. Así que hablemos de una a la vez. Así que cuando vas del resto de tu código a tu módulo cliente de API, esa es una oportunidad para simular cosas allí. En tu prueba Jest, como tu prueba de biblioteca de React Native testing, puedes usar lo que se llama un mock de módulo Jest que dice, hey, en mi prueba aquí, no vayas al módulo cliente de API real. déjame reemplazarlo con uno simulado donde puedo, en mi prueba individual, puedo decir esta vez resuelve la promesa, esta vez rechaza la promesa, como si fuera un error del servidor y cosas así. También puedes reemplazar tu módulo cliente de API con un módulo falso, que es otra versión que tiene la misma interfaz públicamente, pero está escrito de una manera más simple, como en memoria. Escucharemos más sobre eso en breve. También en la capa donde tu módulo cliente de API va a un código de terceros, puede haber una biblioteca de simulación específica de código de terceros. Por ejemplo, Axios tiene Axios mock adapter. Eso es lo que estábamos usando en mi proyecto de cliente actual en la web recientemente. Es un paquete de NPM que es específicamente todo sobre simular Axios en particular. Puede hacer que sea realmente fácil trabajar con Axios, pero también si alguna vez te alejas de esa biblioteca a fetch o algo así, ese adaptador ya no funcionaría. También puedes simular a nivel del soporte de solicitud HTTP subyacente. Así que, dos bibliotecas para eso en el ecosistema de JavaScript son Knock y MockServiceWorker. Usamos esto en mi proyecto de cliente actual, pero Knock lo he usado para proyectos laterales. Hay algunas cosas sobre él que me gustan un poco más que MockServiceWorker para algunos casos. Y así, esto es una simulación, y esto es una cosa buena de estos es que lo que estés usando para las solicitudes HTTP, estos pueden simularlo. Es un poco más estable en ese sentido, pero está un poco alejado de tu código. Finalmente, puedes llegar al punto donde es como, Como, hey, sí, todo mi código de aplicación se está ejecutando normalmente. Pero en lugar de ir a bueno, sabes, en lugar de ir a un servidor web separado, puedes ir a un servidor web local. Así que lo que esto significa es en el desarrollo local o en CI, puedes realmente poner en marcha una copia del backend. Esto podría ser más fácil o más difícil dependiendo de las tecnologías y cómo está escrito en tu estructura organizacional. Para mis proyectos laterales, es bastante fácil decir, quiero decir, yo giro yo tengo un servidor web local para el desarrollo de todos modos. Y así podría tener mi prueba apuntando contra eso. En CI, podría ser más difícil, o tal vez Docker ayuda porque simplemente pones en marcha una instancia o algo así. Así que eso puede ser una opción. La otra opción es lo que podrías llamar un servidor web falso. Así que es, el nombre es un poco raro porque es realmente un servidor web. Como que recibe solicitudes HTTP y te da respuestas, pero está falsificando la funcionalidad, al igual que el módulo falso. Así que está proporcionando una implementación más simple, tal vez solo en memoria, haces solo un simple servidor web de node, sea lo que sea tu backend real, Lo escribes en Node porque eso es JavaScript y estamos acostumbrados a eso. Y tal vez solo almacena los data en memoria. Así que es mucho más simple. Pero una ventaja aquí para el realismo, estás realmente ejecutando a través de todo el stack real en tu aplicación. Solo estás ejecutando contra un servidor web falso. Así que aquí están todas las diferentes opciones. Quiero mencionar el servidor web local en particular porque parece que hay muchos beneficios para el realismo allí, y lo hay.

9. Uso de un Módulo Falso para Pruebas

Short description:

En esta sección, discutimos el uso de un módulo falso en lugar de un servidor web local para pruebas. Explicamos el concepto de un servicio falso y cómo actúa de manera similar a la cosa real pero almacena sus datos en memoria. Al sustituir el módulo cliente de la API con un módulo falso, podemos probar diferentes escenarios en nuestra aplicación React Native. Luego examinamos el código de una aplicación de lista de tareas de código abierto llamada Shirley y su configuración del cliente HTTP. Finalmente, exploramos cómo simular la biblioteca del cliente HTTP autenticado para fines de prueba.

Este es un paso en la dirección correcta. Y esto podría ser lo más fácil para ti si aún no tienes ninguno de estos otros enfoques. Pero una desventaja del enfoque del servidor web local es que aún puede ser difícil configurar los data de prueba que necesitas. Todavía tienes un proceso en ejecución totalmente separado donde tienes que, como, tengo que crear un usuario, tengo que crear algunos data de muestra. ¿Simplemente me registro manualmente? ¿Paso manualmente por todo eso? Así que eso puede ser una desventaja allí. No creo que el servidor web local sea siempre la opción correcta. Es solo otra opción en la caja de herramientas. Para la masterclass de hoy, vamos a hablar sobre el uso de un módulo falso juntos. juntos, no porque sea la mejor opción o la única opción, sino porque hay algunos beneficios específicos que quiero hablar. ¿Puse esos en mis notas? Sí. Bueno, hablemos sobre el módulo falso y verás algunos de los beneficios allí. Así que de nuevo, solo para visualizarlo, este es el módulo falso donde se está ejecutando el resto de tu código de aplicación React Native. Pero en lugar de ir a tu módulo cliente de la API en tu base de código, vamos a ir a un módulo falso en su lugar. Hablemos de por qué. Entonces, ¿qué es el término falso en testing en general? Este término fue acuñado en el libro de patterns de prueba de XUnit, así que recomiendo revisarlo si quieres saber más. Pero un falso es básicamente una versión de un servicio que actúa de manera similar a la cosa real pero almacena sus data en memoria. Esta es una definición un poco más específica de lo que podrías usar en general. Es básicamente una implementación más simple. Ahora, si tienes todas tus llamadas a la API en la aplicación en un solo lugar, que de todos modos es una buena idea, puedes sustituir una versión diferente de ese servicio en las pruebas, incluyendo en tus pruebas de detox. Así que veamos cómo funciona. Y luego podemos hablar sobre los compromisos juntos, porque esto ha sido mucha teoría. Veamos un poco de código. Muy bien. Entonces, para este código, vamos a ver una aplicación de código abierto que tengo en React Native llamada Shirley. Pongámosla en marcha y te la mostraré. Es, lo creas o no, es una aplicación de lista de tareas. De hecho, he construido una lista de tareas aplicación. Está en la tienda de aplicaciones. Soy un nerd sobre las listas de tareas. Eso es cuánto me importa sobre las listas de tareas es que tuve que escribirla yo mismo. Se llama surely, s-u-r-e-l-y, la estoy ejecutando aquí localmente, y ahora mismo la estoy ejecutando contra mi servidor de back-end real localmente. Pero aquí, puedes ver que tenemos un montón de tareas pendientes, es hacer la masterclass react advanced. Esa es una nueva tarea que se ha añadido. Puedes ver una serie de categorías aquí, disponibles mañana, futuro completado, eliminado. Cuando saco la tarea, quiero mostrarte las características básicas de ella Porque durante gran parte de nuestra masterclass, vamos a hablar y mostrar pruebas aquí. Así que tenemos una tarea. Puedo eliminarla. Puedo aplazarla hasta el futuro. O puedo marcarla como completa. También puedo editar la tarea para obtener un poco más de información. Así que hay categorías en las que puedo ponerla. Hay notas que puedo escribir. No hay muchas características. Lo he mantenido intencionalmente bastante simple. Pero el concepto de disponible básicamente significa que puedo trabajar en ello ahora mismo. Y así, si dijera, no tengo tiempo para hacer la compra hoy, será mañana. Puedo aplazarla hasta mañana. Y ahora hacer la compra no aparece en esta lista. Pero si voy a mañana, aparece y digo, no, no va a suceder mañana tampoco. Va a ser más tarde. Entonces la lista de mañana aparece como vacía. Pero en el futuro, agrupado por fecha, veo la tarea de hacer la compra. Finalmente, puedo marcarla como completa. Y entonces se muestra, se va de esta lista aquí. Pero se muestra en la lista completada. Y puedo volver, estoy completado, puedo eliminarlo y cosas así. Así que solo un flujo de trabajo simple para mover las tareas a través de la aplicación. Bastante sencillo. Así que echemos un vistazo. Oh, tengo que sacar mis notas aquí. Así que asegúrate de hablar de las cosas correctas. Sí. Así que eso es Shirley. Aplicación simple de lista de tareas. Pero es lo suficientemente sustancial como para que haya, ya sabes, cosas pasando. Y ciertamente quiero probarlo para asegurarme de que está funcionando bien. Así que echemos un vistazo al código. La mayoría de nuestras solicitudes HTTP en el código en este caso pasan por este archivo llamado cliente HTTP autenticado. Tengo esto porque obtengo un token HTTP de algún lugar y necesito ponerlo en el encabezado. Así que aquí en esta función, lo configuro. Establezco el encabezado de autorización y luego devuelvo. Estoy usando Axios para HTTP y simplemente creo una instancia de Axios y la devuelvo con esos encabezados configurados. Y de hecho, en el resto de la aplicación, uso React Hooks para que cada vez que el token cambia, recreo otro cliente HTTP autenticado, y lo memorizo para que el resto de la aplicación pueda usarlo. Así que esta es mi capa de cliente simple. Notarás que porque devuelvo un cliente Axios directamente, todas sus APIs están disponibles en otros lugares. Podrías tener una versión, un archivo de cliente de API, donde expones un montón de métodos específicos que son específicos para tu aplicación en su lugar. Y ese enfoque funciona totalmente bien para esto también. Así que ahora necesitamos una forma de simular esto. Como queremos tomar ese enfoque de módulo falso. Así que en lugar de usar Axios real conectándose a un servidor backend real, la URL base es ya sea nuestro punto final de API real o las URL locales allí. Así que eso es lo que está pasando allí. Pero no queremos conectarnos a ningún servidor HTTP. Queremos una versión falsa de la biblioteca del cliente HTTP autenticado para esta prueba. Y eso es porque ese es el enfoque que estamos tomando. Así que eso es cliente autenticado punto mock punto JS. Diré que el término mock y falso se utilizan para diferentes propósitos. La documentation de Detox utiliza el término falso. No, la documentation de Detox utiliza el término mock hablando de esto. Y voy a enlazar a eso más tarde para que puedas ver cómo funciona.

10. Módulo Mock para Almacenamiento en Memoria

Short description:

Examinemos el módulo mock que interactúa con un array de JavaScript en memoria para almacenar y recuperar to-dos. No realiza solicitudes HTTP reales, pero proporciona funciones para manipular el array y generar identificadores únicos para nuevos registros.

Así que solo debes saber que X unit test patterns también habla de eso. Pero estoy usando esos términos un poco imprecisamente aquí. Así que veamos este módulo mock para ver cómo funciona. Muy bien, así que ves que tenemos un cliente HTTP autenticado. Esa función está siendo devuelta. Pero en cambio, devolvemos este objeto literal con algunas funciones en él. Así que veamos este archivo paso a paso. Así que en la parte superior aquí, tenemos un array de to-dos que se inicializa a un array vacío. Así es donde se van a almacenar y leer nuestros to-dos. Cuando publicamos o parcheamos to-dos, se van a almacenar en ese array. Cuando obtenemos to-dos, se van a devolver desde ese array. Así que este cliente HTTP mock no está realmente haciendo solicitudes HTTP, solo está interactuando con este array de JavaScript en memoria. También seguimos un próximo ID para que cuando creamos nuevos registros, haya un identificador único para cada uno de ellos.

11. Implementación de Métodos Falsos o Simulados para Post y Get

Short description:

Veamos cómo se implementan los métodos falsos o simulados para post y get. Para post, se verifica la URL para determinar si es el endpoint de to-dos, y si es así, se toman acciones específicas. La funcionalidad de post actualiza el array de to-dos en memoria con un nuevo to-do y devuelve los datos. En cuanto a get, hay dos condiciones basadas en la URL: una para filtrar los to-dos disponibles y otra para recuperar un to-do individual. El array de to-dos se filtra en función de las condiciones de la URL, como disponibles, completados, mañana, futuro o eliminados. Luego se devuelve el array filtrado.

Muy bien, entonces veamos cómo se implementan estos métodos falsos o simulados. Veremos primero el post porque es el más sencillo. Entonces la API, esto no está simulando todo en la API de Axios, solo lo que necesita mi aplicación. Así que llamaré a post, pasando una URL, y pasando el cuerpo, el JSON, verás que dice any aquí porque estoy usando JavaScript, no TypeScript. Pero pasando el cuerpo de la solicitud HTTP.

Entonces, ¿cómo se implementa el post aquí en nuestro simulacro? Así que échale un vistazo. Lo primero que hago es comprobar la URL y digo, ¿es la URL de to-dos, o es algo más? Veamos si hay ejemplos en los registros aquí de las solicitudes. Este es el servidor. Así que eso no va a ser útil. Oh sí, ahí vamos. Sí. Así que solo en mi servicio es un servidor de Ruby on Rails, pero está registrando. Puedes ver una solicitud para.

Oh bien. Eso es eso de nuevo. Déjame. Déjame crear un post para que puedas ayudar a visualizarlo. Así que en los registros aquí, busquemos el post y mientras estás escribiendo un simulacro como este, podrías necesitar mirar los detalles de tu solicitud. Así que sí, échale un vistazo a nuestro back end porque nuestro. No estoy ejecutando el falso ahora mismo en la aplicación react native. aplicación. Estoy ejecutando contra el verdadero backend local. Así que nuestro verdadero backend dice, oh, ha habido una solicitud de post al endpoint de to-dos. Y luego aquí están los parámetros. Es como manipulando los data o algo así, así que no te preocupes por esa parte. Así que estamos diciendo, okay, si un post es al endpoint de to-dos, entonces vamos a hacer algo particular. Este signo de interrogación es solo un factor. Eso es una cosa de cadena de consulta. Es solo un factor del hecho de que fui perezoso en mi código para pasar eso allí. Así que eso no importa. En otros casos, podrías decir simplemente to-dos. Pero el punto es, estoy comprobando condicionalmente la solicitud que está entrando para el resto de mi código. Y si es un nuevo to-do, lo voy a manejar de una cierta manera. En mi caso, la estructura de data para un nuevo to-do, estamos pasando en data.atributos en el cuerpo. Este es un cierto formato de API llamado API de JSON. Y así en mi caso, sé en mi aplicación que data atributos, en realidad, creo que esto está representando el JSON bastante bien. así que nuestro objeto data tiene un parámetro de data tiene un parámetro de atributos y en allí hay hay los atributos de mi objeto así que sé para mi aplicación que voy a sacar esos y los voy a asignar a los atributos en el registro de to-do sé que en mi caso no estoy publicando un ID que se pasa así que necesito asignar un nuevo ID que es el próximo ID que viene de aquí y el JSON API data estructura tiene esta propiedad de relaciones también que no necesitamos para el bien de la testing aquí, pero mi código explotará sin ella. Y así para que mi prueba funcione, añado eso en solo como una relación de categoría vacía en allí. De nuevo, ninguno de estos detalles es general para todas las aplicaciones. Solo para mi aplicación, esta es la estructura que necesita un nuevo TODO. Y luego incremento el próximo ID para que la próxima vez no sea uno, será dos, y luego tres, y luego cuatro. Y luego mutuo el array de TODOs. Empujo el nuevo TODO al array de TODOs. La mutación está bien aquí porque esto no está en el ciclo de vida de React. Este es solo un código separado. Supongo que se está ejecutando a través de React, pero no necesito nada para ser actualizado aquí. Esto es solo data que se ejecuta en este servicio, al igual que tu verdadero servidor backend muta data y cambia cosas. Y así soy capaz de mutar el array aquí. Y luego hago un retorno. Así que mi endpoint de post tiene un cuerpo de retorno. Eso es parte de la especificación de la API de JSON que también sigo. Devuelve una propiedad data con el to do con todos sus atributos. Así que lo devuelvo. Así que cuando el resto de mi código de aplicación llama a post, esta funcionalidad va a ser ejecutada, y luego en este array de to-dos en memoria, va a ser actualizado con un to-do, y obtengo los data de vuelta. Así que tal vez estoy insistiendo demasiado en esto, pero pensando en la aplicación, cuando estoy ejecutando la aplicación real, va a llamar a post contra esta instancia de Axios. Cuando he configurado mi prueba de detox para usar el simulacro en su lugar, y veremos cómo configurar eso en un momento, entonces va a llamar a esta versión falsa del post para operar con estos data en memoria en su lugar. Actualmente aquí, así que eso es lo que pasa cuando publico un to-do. ¿Qué pasa con otras cosas que podría publicar? Bueno, solo puse un atrapador aquí. Actualmente, mis pruebas no requieren ningún otro manejo para nada. Creo que puedo crear una categoría, y también puedo crear un usuario, pero mis pruebas no necesitan hacer eso todavía. Así que he tomado el enfoque pragmático en mi falso aquí para implementar solo lo que es necesario para que mi prueba actual pase. y ese enfoque incremental puede ser muy útil mientras estás empezando en testing tu aplicación. Así que eso es el post. ¿Qué pasa con el get? Echemos un vistazo a eso. Así que get es en HTTP semántica es cargar data desde el servidor. Así que échale un vistazo. Tengo dos condiciones aquí. URL comienza con to-dos pregunta o URL comienza con to-dos barra. Déjame mostrarte eso en la aplicación para que puedas tener una idea de para qué es eso. Así que si recargo la aplicación y abro la página disponible está diciendo vamos a encontrarlo aquí obtener el endpoint de to-dos y luego hay algunos argumentos pasados en filtro estado igual disponible así que esa es la forma en que pasamos al servidor el hecho de que estoy obteniendo los to-dos disponibles si voy a otra pantalla por ejemplo y básicamente el back end está realmente en control de todas estas listas así que si voy a la pantalla de mañana vas a ver una entrada de registro aquí para to-dos filtro estado igual mañana. Así que el front end no le dice al back end qué fecha consultar. La forma en que lo he configurado, dejamos que el back end nos diga cuáles son los to-dos de mañana. Es solo la forma en que sucedió implementar. Así que necesitamos falsificar esa funcionalidad en nuestro falso o simulacro cliente HTTP porque nuestra aplicación depende del back end para eso. Así que necesitamos una forma de obtener to-dos disponibles y to-dos de mañana y los otros también. Así que primero confirmamos. Oh, déjame explicarte este otro a ti también así que esto esto to do es barra porque estamos diciendo que la url comienza con to do barra eso es para sacar un registro individual así que si voy aquí y hago clic en este un registro va a esta página y luego sí así que decimos obtener to-dos barra y luego aquí está un uuid así que el real back end usa uuids para distinguir registros um y hay algunas otras cosas en allí también um pero sí así que cuando vamos a una página individual el to-do individual se carga y hago eso porque no quiero confiar en los viejos data que son de la lista. Como cuando abro esta página, quiero asegurarme de que estoy obteniendo los últimos data del servidor. Es solo la forma en que construí la aplicación. Así que to-dos barra es una solicitud para un to-do individual. Así que veamos cómo se implementa cada una de estas partes. Así que estoy obteniendo una lista de to-dos. Tomo el array de to-dos y ahora necesito filtrarlo. Necesito filtrarlo basado en las condiciones. Así que estoy comprobando, ¿la URL incluye disponible, completado, mañana, futuro, o eliminado? Podría analizar la cadena de consulta para obtener información muy detallada, pero encontré que en mi caso es suficiente con usar una rápida expresión regular para probar la URL contra. Bueno, ¿qué pasa si estoy pidiendo los to-dos disponibles? Bueno, voy a mirar a través y filtrarlo. Hay un campo completado en un to-do, y me aseguro de que eso sea nulo porque si está completado, no está disponible. También eliminado en. Así que cuando elimino to-dos, los mantengo en la aplicación porque tengo esa pantalla eliminada donde necesitamos mostrarlos. Pero solo digo, oh, sí, solo si un eliminado en es nulo, ¿está disponible? Uso igual igual aquí solo porque si es indefinido, eso está bien también.

12. Uso de un Cliente HTTP Falso

Short description:

Para crear un cliente HTTP falso, reimplementamos parte de la lógica del backend en nuestras pruebas de frontend. Esto nos permite probar los flujos de forma incremental y navegar los compromisos de las pruebas automatizadas. Tomamos atajos en la implementación falsa para simplificar el proceso. Para la solicitud get, devolvemos un registro de datos con un to-do. Registramos las URL que no han sido simuladas para identificar cualquier comportamiento inesperado. También tenemos una solicitud de parche para hacer cambios en un to-do, siguiendo la especificación de la API de JSON. Este es nuestro cliente HTTP falso para la aplicación de lista de to-dos. Personalizamos el archivo Metro config.js para usar el simulacro en lugar del cliente HTTP real en nuestras pruebas de detox.

También aplazado hasta. Así que el campo aplazado hasta es cómo rastreo si se ha aplazado para el futuro. Y si eso está en blanco, está disponible. Y si todas estas cosas son ciertas, devuelvo registros en la lista. Ahora, porque conozco el backend, sé que hay algo aquí que no es del todo preciso. No es solo cuando algo no está aplazado que está disponible. Digamos que creé un to-do hace una semana y lo aplacé hasta ayer. Bueno, hoy, ese to-do que fue aplazado hasta ayer está disponible. Así que hay algo de lógica de fecha que realmente necesita ejecutarse para ser completamente preciso en la lista disponible. Pero descubrí que hasta ahora, en mis pruebas, no he necesitado eso. Ese es un buen caso para cubrir, aunque en realidad eso es realmente más en la lógica del backend. En mi caso, el backend tiene la lógica que dice cuándo las cosas están aplazadas y cosas así. Y por eso tengo pruebas exhaustivas para esas en mi código de backend. ¿Necesita mi frontend probar eso? No necesariamente. E incluso si lo hace, como tal vez no es, es menos valor. Tal vez lo pruebo a nivel de unidad en lugar de a nivel de prueba de extremo a extremo. Pero realmente estoy sintiendo ahora mismo, no lo he pensado super a fondo. Creo que eso es una preocupación de testing de backend. No creo que el frontend necesite preocuparse por eso. Pero sí necesito hacer esto porque esto me da algo de realismo que podría ir incrementando a través de mi aplicación para probar los flujos. Así que esto es una especie de reimplementación de la lógica del backend para filtrar por disponible. Completado es similar. Para una prueba completada, nos aseguramos de que la aplicación completada no sea nula. Así que ha sido marcado como completado, pero asegúrate de que no esté marcado como eliminado, porque en mi aplicación, cuando lo marcas como eliminado, también lo saca de la lista completada. Así que mientras piensas en estas cosas, como tu mente puede estar dando vueltas un poco, especialmente porque no has trabajado en esta aplicación. Y es como, wow, como para hacer que este falso funcione, estamos teniendo que reimplementar mucha de la lógica que existe en nuestro backend. ¿Realmente vale la pena? Y ese es el compromiso. Ese es el compromiso que necesitas pensar. ¿Quieres no tener testing automatizado y solo hacer testing manual para todo? Puede parecer más sencillo, pero eso es mucho testing manual que tienes que hacer cada vez que haces una versión de tu aplicación. Podrían ser semanales si quieres que sea realmente fresco. Arte más, tal vez solo correremos contra el verdadero backend. Pero entonces tienes escamas. Tal vez solo correremos contra una copia localmente ejecutada del backend, pero tal vez eso sea difícil de configurar. O tal vez funcione genial para ti de nuevo. No estoy diciendo que siempre necesites usar una API falsa o simulada como esta, pero esos son los compromisos. Esto no fue realmente mucho trabajo para implementar en mi simple aplicación de to-do. Descubrí que este cliente HTTP falso o simulado es útil, pero hay un poco de reimplementación allí. ¿Es menos realista porque no estamos yendo contra el backend? Sí, pero estos son los compromisos que necesitas navegar mientras trabajas en la implementación de testing tu aplicación. Tal vez un falso o simulacro vale la pena, y tal vez no lo es. Y al final de la masterclass, hablaremos de cómo puedes abordar las cosas gradualmente para sentir las cosas. Pero en este caso, hemos reimplementado un poco de esta lógica, solo una expresión booleana para obtener un falso que funcionará para nuestros propósitos. Realmente brevemente, veamos aquí. para la solicitud get para un to-do individual. Es bastante simple. Solo devolvemos un registro de data con un to-do. Aquí hay otro atajo que tomé. Sería bastante simple sacar el ID del registro de to-do y cargarlo del array de to-do, pero descubrí que para mi prueba, no necesitaba eso realmente, así que decidí hacer trampa un poco, y solo estoy obteniendo el primer to-do en todos los casos. Eso podría ser más sencillo para algunas pruebas. También podría ser confuso para ti más tarde cuando descubras que no estás sacando el to-do que pensaste que estabas, Y así, quiero decir, no es mucho trabajo obtener el, el ID de la URL y luego hacer una búsqueda en este array para obtener el registro correcto. Pero de nuevo, solo quería ilustrar, puedes tomar atajos en tu falso, porque esa es la tensión quiero decir que vas a oírme hablar de compromisos todo el tiempo. Podrías decir como, oh, esto es esto es preocupante porque no es la implementación real que quiero una implementación más realista, pero con una implementación más realista podrías sentir como, wow, eso es mucho trabajo, no sé si quiero hacer testing en general. Es muy fácil convencerte de no hacer ninguna testing mientras navegas estos compromisos. Pero lo que quieres hacer es pensar en los pros y los contras y decidir qué enfoque funciona para ti. Así que para mis pruebas, solo necesitaba obtener la lista de to-dos y to-dos individuales o en otros casos. Así que esto es algo que descubrí que es útil es realmente registrar. Como hay otras solicitudes get en mi aplicación. Solo estoy devolviendo data vacíos para ellas, pero quería seguir adelante y registrar. Oye, esta es una URL que no ha sido simulada. De esa manera, si una prueba no se comporta como espero, puedo obtener información en los registros para ver, oh, sí, esa no es una URL simulada. Tal vez esa sea la razón por la que una prueba no se comporta como espero. Tal vez realmente quiero simular esa URL en su lugar. Así que ahora hemos visto get. Hemos visto post. Te mostraré el parche solo por el bien de la integridad. En realidad no uso elimina en esta aplicación porque, como mencioné antes, mantenemos una fecha eliminada para que puedas ver la fecha en que algo fue eliminado. Así que puedes traerlo de vuelta a la basura o lo que sea. Así que tengo parche. La única solicitud de parche es para hacer cambios en un to-d

13. Configuración del Backend Simulado para Pruebas de Detox

Short description:

Configuramos la configuración predeterminada para Metro y agregamos una clave de resolución con extensiones de origen. Si la variable de entorno de la API simulada está configurada en verdadero, priorizamos la extensión mock.js para los módulos. Configuramos la variable de entorno de la API simulada utilizando un script NPM recomendado por Detox. Esto nos permite cambiar al modo simulado y ejecutar la aplicación localmente. Ahora podemos probar nuestro servidor de API simulada, que comienza sin to-dos por defecto. Agregar un to-do y hacer cambios se reflejan en la aplicación, incluso después de recargar, confirma que estamos utilizando el backend simulado. El nuevo comienzo en cada prueba de Detox mejora el aislamiento y la consistencia de las pruebas. Este enfoque falso en memoria proporciona puntos de partida predecibles y aumenta la confianza en las pruebas. Con el backend simulado configurado, ahora podemos ejecutar pruebas sin un backend y beneficiarnos de la previsibilidad.

Obtenemos toda la configuración predeterminada. Aparentemente, tenemos que pasar en Derny. Solo estoy usando el código generado. Pero obtenemos toda la configuración predeterminada para metro. Pero añadimos una cosa más. Añadimos esta clave de resolución. Y estamos configurando las extensiones de origen. Y ahora es donde entra la condición. Estamos comprobando process.env.mockapi. Esta es la API de node para obtener una variable de entorno. Y decimos, oh, OK, si mock API está configurado en verdadero, hacemos una cosa. De lo contrario, hacemos otra cosa. Así que si no está configurado en verdadero, por defecto, configuramos las extensiones de origen en las extensiones de origen predeterminadas. Tiene sentido. Estamos usando la configuración predeterminada. Pero si mock API está configurado en verdadero, y eso es solo una variable de entorno que hemos inventado, podría llamarla como quiera. Si mock API está configurado en verdadero, vamos a añadir algo al frente. decimos, oh, está bien, si mock API está configurado en verdadero, primero busca una extensión mock.js, tal como hemos hecho aquí. Si ves una extensión mock.js, úsala como primera prioridad. Pero si no la ves, vuelve a las extensiones de origen predeterminadas como JS o lo que sea. Así que esto está diciendo, quiero decir, he hablado y verbalizado los detalles, pero esto está diciendo básicamente, si configuramos esta variable de entorno, busca una versión simulada de cualquier módulo y úsala si está presente. Eso nos permite simular no solo el cliente HTTP autenticado, sino también en mi caso, hay un cliente HTTP de inicio de sesión que necesito usar, o otros simulacros que quieras usar en otro lugar. Así que somos capaces de simular la API. Con eso, ahora tenemos esta variable de entorno que nos va a permitir cambiar el comportamiento. ¿Cómo la configuramos? Bueno, hay muchas formas diferentes, pero la forma que recomiendan los documentos de Detox es crear un nuevo script de NPM. Así que puedes ver aquí, tengo el script de inicio predeterminado que ejecuta Expo start en mi aplicación de Expo. La CLI de React Native sería diferente allí. Pero he añadido un comando de inicio de colon mock que lo inicia con mock API configurado en verdadero al frente. Así que eso va a configurar esa variable de entorno, que Metro a su vez va a usar aquí. Así que con eso, somos capaces de ejecutar en modo de inicio de colon mock para habilitar nuestra simulación. Así que esto es útil. Esto puede ser usado no solo en Detox, sino también al ejecutar la aplicación localmente. Y eso puede ser útil mientras configuras estos simulacros también. O tal vez el servidor de back-end está caído y quieres poder tener el back-end simulado. Así que vamos a darle una prueba y ver cómo funciona. Recuerda, en mi aplicación en ejecución aquí, nos estamos conectando al back-end real. Vimos esas solicitudes de back-end real siendo ejecutadas. Así que ahora en cambio, voy a detener mi servidor Expo en ejecución. Dejame sacar mi cosa de Zoom del camino. en lugar de yarn start voy a ejecutar yarn start mock puedes ver que en realidad se ha mostrado aquí mock API igual a verdadero expo start y se levanta no he mantenido las cosas al día así que ahí vamos pero eso está bien y nuestra aplicación comienza ahora en mi simulador local puedo recargarlo y está cargando desde el back-end así que ahora vamos a darle a nuestra API falsa o servidor de API simulada una prueba. Observa. Ahora no tengo ningún to-do disponible. Y por lo tanto, no se están mostrando. Eso es porque en mi back-end simulado por defecto, comienza sin to-dos. Así que vamos a añadir uno, prueba de API simulada y presiona return. Presiono return y aparece en la lista. Y desde aquí puedo cambiar cosas. Puedo decir añade algo de entusiasmo allí si yo mock API, y aparece. Si voy a otra pantalla y vuelvo, está allí. Y esto y voy a recargar manualmente solo para asegurarme, sabes, esto está recargando desde el servidor de backend. Así que todos estos cambios aparecen a medida que avanzo. Si lo marco como completo, entonces va a aparecer aquí. Aparece en la lista completa. Si lo marco como eliminado. Aparece en la lista de eliminados y la forma en que esta aplicación está configurada, estoy usando un bastante seguro que estoy usando React query. Y así tomando ese enfoque de dejo que el servidor sea autoritario y no almaceno mucho localmente. Recargo cada vez que voy a una nueva pantalla. Y eso está golpeando el back-end aquí para obtener los to-dos. Otra cosa que puedo mostrarte para aumentar tu confianza en que estamos usando el back-end simulado aquí. Bueno, una cosa es que puedo detener el servidor de desarrollo local en ejecución y asegurarme de que las cosas siguen funcionando. Oh, mira esto. Así que aquí está una limitación de ese enfoque que hice. Recuerda, get, cuando obtengo un to-do, siempre devuelvo el primero. Así que aunque configuré un segundo to-do aquí, cuando lo saco, al recuperar ese to-do, saca el primero. Realmente fui muy perezoso cuando configuré eso. Y así que tal vez eso sea terrible. No necesariamente recomiendo hacer esto. Tal vez quieras seguir adelante y encontrar el to-do en la lista para que tus pruebas sean más realistas. Pero dicho esto, mira esto. Observa lo que pasa cuando recargo la aplicación React Native. Mis to-dos se han ido. Completado. eliminado, no está allí. Obtengo un nuevo comienzo. Así que podrías pensar que esto es un problema. Esto es una desventaja. De nuevo, hay compensaciones para todo. En realidad hay una gran ventaja para las pruebas automatizadas. Sabes, cuando Detox inicia tu aplicación, recarga React Native. Y así estás obteniendo un nuevo comienzo en cada una de tus pruebas. Eso es realmente genial para el aislamiento de pruebas, de modo que cada vez que inicias una nueva prueba de Detox, no tienes data de otras pruebas que estén ensuciando las cosas. estás obteniendo un nuevo comienzo. Eso facilita la escritura de pruebas que siempre son consistentes. ¿Es más realista para tu prueba obtener un nuevo comienzo cada vez que cargas tu aplicación? No, pero ¿aumenta tu confianza en tus pruebas? Sí, porque tus pruebas están obteniendo un punto de partida predecible. Así que esto es en realidad un gran beneficio de usar un falso en memoria como este. Esta es una de las razones por las que prefiero esto para las pruebas de detox sobre otros enfoques para simular. Así que no voy a ejecutar las pruebas todavía. Vamos a ver esas pruebas en, creo, la próxima sección cuando echemos un vistazo a algunas de las pruebas de Detox que tenemos. Pero ahora tenemos nuestro back-end simulado configurado. Así que ahora sin ningún tipo de back-end en ejecución, somos capaces de ejecutar esas pruebas. Estamos obteniendo el beneficio de la previsibilidad.

14. Configuración y Uso de un Módulo Falso

Short description:

Estamos obteniendo el beneficio de la independencia. Todo lo que necesitamos hacer en CI es poner en funcionamiento nuestra aplicación React Native, lo cual es lo suficientemente difícil sin tener que preocuparse por poner en funcionamiento un backend también. En nuestra configuración de archivo de API aquí, estamos usando un nombre general. Si tuvieras un archivo api.js, puedes crear un api.mock.js. Tienes un segundo archivo para ese backend simulado. Después de configurar Metro.config.js, crea un script y un paquete JSON que pasa la variable de entorno en el frente. Si estás en Windows, necesitas instalar el paquete cross env. Eso es lo que es un módulo falso. Así es como se configura y cómo se conecta en una aplicación React Native. Si estás usando React Relay, puedes crear una versión falsa del módulo o usar herramientas específicas del marco para simularlo. También puedes usar capas de simulación de HTTP como Knock y Mock Service Worker o un servidor GraphQL en funcionamiento local. Es importante considerar los compromisos y decidir si las pruebas automatizadas valen la pena para tu aplicación.

Estamos obteniendo el beneficio de la independencia. Todo lo que necesitamos hacer en CI es poner en funcionamiento nuestra aplicación React Native, lo cual es lo suficientemente difícil sin tener que preocuparse por poner en funcionamiento un backend también. Así que volvamos a las diapositivas. y repasemos un poco lo que hemos hecho aquí para poner en funcionamiento este módulo de API falso. Así que en nuestra configuración de archivo de API aquí, estoy usando un nombre general. Si tuvieras un archivo api.js, puedes crear un api.mock.js. Tienes un segundo archivo para ese backend simulado. En nuestra API, que tenemos aquí, comenzamos, con un ejemplo general de lo que vimos en mi aplicación. Así que si estás usando Axios, y estás creando una instancia y haciendo alguna configuración, entonces en el API mock, creas solo un objeto en memoria que tiene la misma interfaz, los mismos métodos o funciones disponibles, pero solo estás devolviendo datos falsos en su lugar. En este ejemplo aquí, solo tengo datos codificados. Así que si tuvieras datos de solo lectura, podrías codificarlos aquí para devolver algunos datos en su lugar. O como vimos en el código de Shirley, puedes crear algunos datos modificables como un array o datos en memoria y JavaScript que se mutan a medida que avanzas. Y solo como recordatorio, Shirley es de código abierto Y por lo tanto, ese código fuente está disponible desde la página web de la masterclass. Puedes ir allí y descargarlo y probarlo tú mismo.

Ahora para hacer este falso utilizable, usamos metro.config.js, el archivo de configuración. Así que queremos configurarlo para que cuando esa bandera esté establecida, cuando esa variable de entorno esté establecida, prefiramos la extensión mock.js cuando ese archivo esté presente. El código exacto en tu archivo puede diferir si estás usando React Native CLI versus Expo, o si has modificado metro.config.js por otras razones. Así que solo tienes que seguir las instrucciones de Detox. Si he puesto esta información en reactnativetesting.io para que sea fácil de acceder allí, pero acredito, hey, es de Detox, ellos lo configuraron. Por favor, acude a ellos con preguntas si algo deja de funcionar y enlazo con sus instrucciones también. Así que esta es una URL a la que puedes ir. Como nota rápida, las diapositivas ya están disponibles para la masterclass en la página web de la masterclass. Así que puedes obtener esas diapositivas para obtener esos enlaces localmente, pero también enlazo directamente a React y testing desde la URL de la masterclass también.

Así que después de haber configurado Metro.config.js, quieres crear un script y un paquete JSON que pasen esa variable de entorno al frente. Así que si estás en un sistema basado en Unix como macOS o Linux, esto funcionará perfectamente. Solo quería mencionar porque hay gente en Windows, tal vez incluso gente de Android en Windows. Y así que si estás en Windows, Windows no está basado en Unix y por lo tanto no funciona de la misma manera. necesitas instalar este paquete cross env. Es un paquete NPM. Esa es una forma de establecer variables de entorno y pasarlas a tu script. Así que si usas este enfoque, si necesitas soportar entornos de desarrollo de Windows, cross env te ayudará allí y también funcionará bien en Mac OS y Linux.

Así que eso es lo que es un módulo falso. Así es como se configura y cómo se conecta en una aplicación React Native. Y durante el descanso, Víctor del chat compartió una pregunta. Y realmente lo aprecio. Es una gran pregunta. Así que hablemos de ello. Y Víctor pregunta, ¿cómo falsificas un punto final de GraphQL, por ejemplo, con React Relay? Así que sí, estoy feliz de responder a eso. Y no he usado React Relay yo mismo. He hecho algo limitado con GraphQL usando Apollo. Pero lo que puedo decir es basado en este marco conceptual del que hablamos, puedo hacer sugerencias de cómo puedes investigarlo. Y, Víctor, puedes probarlo, o otros espectadores con otras bibliotecas para conexiones pueden probarlo y compartir con la comunidad cómo funcionó.

Así que, como mencioné, este diagrama muestra una pila específica con Axios y HTTP. Así es como funcionaría con React Relay. Así que tienes el resto de tu aplicación que depende de, sabes, solo tu UI. Y luego en algún momento, estás llamando al código de React Relay. Ahora, no sé, porque no he usado Relay. si hay un módulo de JavaScript o TypeScript que tú mismo escribes. Si lo hay, entonces podrías usar el enfoque de simulación o falso que hemos recorrido juntos para crear una versión falsa de eso. Y cualquier dato o cualquier función que configures allí para configurar React Relay, puedes crear versiones falsas en su lugar. Y eso podría ayudar posiblemente. La otra opción, la siguiente capa es la capa específica del marco. Aquí es donde está Axios y React Relay se sentaría allí. Así que puedes usar herramientas o paquetes específicos del marco para simular eso. Y cuando hice una búsqueda, me encontré con, lo que parece ser la página web de Relay, una página sobre pruebas de componentes de Relay. Y solo eché un vistazo rápido en el último poco. Esto está hablando de cómo probar los componentes de Relay. Este es un enfoque de prueba específico de Relay. Ahora, esto podría funcionar solo para la capa de Jest y React Native Testing Library. Así que tendrías que probarlo para ver cómo funcionó. Esto podría o no funcionar para Detox, pero ese es un enfoque específico de la biblioteca que podrías investigar. Y lo publicaré en el chat para que Víctor tenga acceso a él. Y si estás viendo la grabación, puedes acercarte o simplemente buscarlo, pruebas de componentes de Relay, en el sitio web de Relay. La otra opción sería que GraphQL no está realmente vinculado a HTTP, pero casi siempre que yo sepa, GraphQL se usa a través de HTTP. Y así finalmente GraphQL está haciendo solicitudes HTTP. Y así podrías usar capas de simulación de HTTP como Knock y Mock Service Worker. Y cuando trabajé en un proyecto hace unos años usando GraphQL, exploramos la simulación a nivel de HTTP. Podría haber un poco de duplicación allí porque la mayoría de las solicitudes HTTP de GraphQL se ven igual, pero esa es una opción también. Así que probablemente podrías probar Knock o Mock service worker configurado para React-native. Y no hemos repasado los detalles sobre eso, pero esa podría ser una opción para simularlo también. Y por supuesto, un servidor GraphQL en funcionamiento local, o no he buscado opciones para servidores fal

15. Beneficios de las Pruebas y Asistencia de Expertos

Short description:

La biblioteca de pruebas de React Native es fácil de configurar. Considera los beneficios de las pruebas e invierte en tu conocimiento de pruebas. TestDouble puede proporcionar asistencia experta en React Native y pruebas. No te pierdas los beneficios de las pruebas debido a la fricción de la configuración.

Y como tal, tienes que decidir por ti mismo. La biblioteca de pruebas de React Native es muy fácil de configurar. Y tal vez obtienes suficiente confianza y realismo de la biblioteca de pruebas de React Native. Y cortas la parte superior de la pirámide de pruebas y no necesitas la capa de detox. Pero yo diría, piensa en tu competencia. ¿Sigues teniendo que hacer muchas pruebas manuales? ¿Los errores llegan a producción porque las cosas no se probaron de extremo a extremo? Si es así, ese es el costo para la organización, costo para la fiabilidad de la aplicación que puede hacer que valga la pena pasar por esta configuración para hacer funcionar detox. Y a medida que aprendes sobre pruebas, como ingeniero de software en general, esos principios se mantienen. Los principios de los patrones de pruebas de la unidad X se han mantenido desde 2007. Y así, si y cuando tienes tiempo, invertir en tu conocimiento de pruebas puede ser beneficioso. Así que mi consultoría, TestDouble, en realidad no me está patrocinando para estar aquí. Este es solo un día de vacaciones. Pero diré, si necesitas ayuda, traer a un experto puede ser una gran idea. TestDouble estaría encantado de ayudar. Hay otras personas que conocen bien React Native y las pruebas. Tal vez puedas traer a alguien para ayudarte a superar el obstáculo de configurar las cosas. Y luego estás listo para ir. No dudes en ponerte en contacto con Test Double o conmigo usando la información de contacto en el enlace de abajo si podemos ayudarte con esto. Odio que la gente se pierda los beneficios de las pruebas debido a toda esta fricción para configurarlo. Por eso comparto contenido como esta masterclass para intentar ayudar.

16. Pruebas con Detox y Beneficios

Short description:

En esta parte, discutimos cuánto probar con detox y los beneficios de ejecutar incluso una prueba mínima. Mostramos ejemplos de diferentes formas de usar detox, como probar el botón Acerca de en el cajón. También demostramos la importancia de probar los principales indicadores de la pantalla correcta, como el encabezado disponible. Estas pruebas proporcionan confianza en el proceso de construcción de la aplicación, el lanzamiento exitoso y la prevención de fallas. Son especialmente útiles cuando se utiliza Dependabot para actualizaciones automáticas de dependencias y se ejecuta la suite de pruebas completa en las solicitudes de extracción. Incluso configurar una prueba de arranque con detox puede proporcionar beneficios significativos en términos de confianza en la aplicación.

Muy bien, entonces sigamos. Si has pausado el video por un tiempo para procesar eso y estás volviendo, si estás viendo esto más tarde, pasamos al siguiente tema, que es cuánto probar con detox. Y lo que quiero decir específicamente es como, bueno, como hemos decidido que estamos haciendo unit testing y vamos a usar las pirámides de prueba. Entonces, un montón de pruebas de nivel inferior y algunas pruebas de detox, pero no todas. Entonces, ¿cuánto es algo, cuánto detox testing hacemos? Y si ya tengo una gran aplicación que está en marcha, ¿cómo supero el estrés de cómo puedo hacer que las pruebas se ejecuten para todo eso? Entonces, seguramente he configurado una secuencia de pruebas, comenzando con la fruta más baja, las cosas mínimas que puedes escribir para poder obtener algún nivel de confianza. Y lo que encuentras es que después de esta configuración, solo agregar una prueba de detox que da un poco de testing allí agrega muchos beneficios. Y entonces puede comenzar a dar sus frutos muy rápidamente. Y luego puedes agregar más pruebas a medida que encuentras el valor.

Entonces, vamos directamente al código para hacerlo muy concreto esta vez para ver. Vamos a ver ejemplos de diferentes formas de usar detox, y luego volveremos a las diapositivas después y hablaremos sobre los conceptos. tips. Así que volvemos a Shirley de nuevo para ver las suites de prueba disponibles aquí. Así que he configurado algunas pruebas aquí. No siempre numero mis pruebas así, pero fue útil aquí para el propósito de esta presentación para mostrar una especie de secuencia. Entonces, la primera prueba que configuré, la llamo la prueba de arranque. Y lo que hace esto, si has mirado detox antes, esto es algo así como la placa de caldera al comienzo de la prueba de detox que lanza la aplicación al comienzo y recarga la aplicación antes de cada prueba. Todo lo que estoy testing aquí es que debería mostrar el botón Acerca de en el cajón. El botón Acerca de es este, está implementado como un botón. Hice clic en el botón de navegación de alternancia aquí para alternarlo y me aseguro de que el botón de navegación Acerca de esté visible. Estoy usando identificadores de prueba aquí, y entonces, vamos a ejecutarlo. Vamos a ejecutar pruebas en esta masterclass de testing para demostrar a creo que sí. Para ejecutar si no lo has visto antes, para ejecutar una prueba de Detox, vamos a hacer Detox tests iosim.Release. Solo como una nota, si has usado Detox antes, a menudo tienes debug y compilaciones de lanzamiento configuradas dentro de Detox. Lo que encontré trabajando dentro de Expo, no he sido capaz de hacer funcionar Detox con Expo para las compilaciones de debug. Ejecutando ejecutando en Expo Go o incluso en un cliente personalizado. Cuando haces una compilación de lanzamiento, simplemente se convierte en una aplicación construida de React Native. Y por eso creo que Detox es capaz de interactuar con él de manera más clara. Hay una configuración muy compleja en estas cosas. Y Detox, quiero decir, es una herramienta de código abierto haciendo cosas muy complejas. Y por lo tanto, no apoyan oficialmente a Expo, y no les guardo rencor por eso. Como, gracias, Wix por hacer y mantener Detox. Y entonces, sí, en Expo, el modo de lanzamiento de Detox es lo que he podido ejecutar. Y de esa manera, es la aplicación construida con la que probamos. Así que ejecuto Detox Test, modo de lanzamiento, y luego voy a especificar el archivo. Solo ejecutaremos la prueba de arranque. Entonces, cuando ejecuto esto, voy a mover esto para que podamos verlo. Está arrancando. Ves que abre la aplicación. Saca el sidebar allí, y ves que la prueba pasa. Entonces dice, sí, debería mostrar el botón Acerca de en el cajón. Y lo confirmamos. Y siempre es una buena idea con las pruebas asegurarse de que las has visto fallar. Entonces, voy a cambiar el ID a un ID que realmente no está allí, porque quiero que se asegure de que la prueba falla si el elemento que está tratando de encontrar no se encuentra. Especialmente con las pruebas de React Native y las aplicaciones de front-end ricas, puede ser muy fácil que una prueba pase incorrectamente. Así es como se ve cuando falla. Dice, no se encontraron elementos del matcher, botón de navegación incorrecto. Así que está bien. Y debido a la forma en que funciona Detox, la aplicación todavía está en el simulador, por lo que podría jugar y mirarla, incluso usando herramientas de inspección para averiguar qué está pasando. Voy a poner el botón de navegación Acerca de de nuevo. Asegúrate de que pasa de nuevo. Entonces pasa. Entonces, esta es una prueba bastante trivial. ¿Es esto realmente útil? ¿Qué nos da esto? Bueno, nos da mucho, en realidad. Entonces, ¿qué es necesario para que tu aplicación arranque? Bueno, necesita construirse. Ese es el comando de construcción de detox separado. Pero en CI, tu aplicación necesitará construirse. Y por lo tanto, el proceso de prueba de CI fallará si tu aplicación no se construye con éxito. También se asegura de que se lance con éxito, que no se bloquee al lanzar debido a algún código nativo. Todos sabemos que las actualizaciones de React Native pueden ser desafiantes. Y eso asegurará que no se bloquee al lanzar. Además, que el JavaScript no se bloquee con un error cuando tu aplicación se inicia. Así que esto está confirmando que no solo la aplicación se está levantando, sino que algunas cosas en la pantalla que son específicas de mi aplicación también se están levantando. Así que eso nos lleva bastante lejos. Eso está testing a través de esa pila profunda que vimos para asegurarnos de que la aplicación se levanta. Un lugar donde estos son especialmente útiles, utilizo Dependabot para actualizaciones automáticas de dependencias. y ejecuto, no para Shirley porque Expo en CI era difícil, pero en otras aplicaciones, ejecuto mi suite de pruebas completa, incluyendo pruebas de extremo a extremo en las solicitudes de extracción. Y entonces, cuando Dependabot crea solicitudes de extracción para todas estas nuevas dependencias que se actualizan, cada una me dirá, oye, la construcción falló o la prueba de extremo a extremo falló debido a esta actualización de dependencia. Y entonces sé que no es seguro fusionar esos. Otros que sí pasan, trato de configurar mi aplicación para que tenga bastante confianza de que puedo fusionarlos. A veces, dependencias realmente complejas como React Navigation. Estoy como, sí, déjame probar esto localmente para asegurarme antes de fusionar esa actualización de dependencia. Quiero un poco de testing manual allí en ese caso. Pero una biblioteca como Formateo de Fecha o Clases de Utilidad o ESLint, como, sí, voy a seguir adelante y fusionar cuando CI pasa. Entonces, incluso si configuras Detox y consigues que funcione una prueba de arranque y eso es todo, no haces nada más, eso ya te está dando algunos beneficios significativos en cuanto a la confianza en tu aplicación. Ahora, hay algo que es instructivo aquí que quería hablar, sobre por qué estoy testing el botón Acerca de. Eso parece un poco extraño. Podría buscar un inicio de sesión o decir si inicio sesión aquí, podría buscar disponible. A menudo, lo primero que me viene a la mente es ¿cuál es el principal indicador de que estoy en la pantalla correcta? Así que ver la lista disponible o incluso el mensaje No tienes tareas pendientes disponibles, eso parece una de las cosas más útiles para probar. Entonces, probemos eso. Tengo una versión comentada de esa prueba. Intentemos buscar el encabezado disponible. Tengo que hacer un índice aquí porque disponible también aparece en la barra lateral. Y entonces la aplicación lo ve y lo encuentra detox lo encuentra. Así que ejecuto la prueba y pasa. Bueno, eso parece un poco más instructivo, como el disponible encabezado, como la pantalla disponible parece más importante que el acerca de. ¿Correcto? Entonces, ¿por qué hice eso de manera diferente? Entonces, déjame mostrarte. Cierro sesión aquí en este simulador local y ejecuto la prueba de nuevo. ¿Qué crees que va a pasar? Veamos. La aplicación se lanza y la prueba falla.

17. Pruebas de Inicio y Juego

Short description:

En la prueba de inicio, nos aseguramos de que la aplicación se inicie y el elemento de navegación acerca de indique si el usuario ha iniciado sesión. La prueba de juego confirma el estado inicial y realiza operaciones básicas del usuario como crear y editar tareas pendientes. Aumenta la confianza en la lógica de la aplicación. La prueba pasa, indicando que todas las acciones esperadas ocurrieron. Aunque el campo de fecha está indefinido, no afecta la funcionalidad de la aplicación. La prueba del formato de fecha se puede hacer en niveles inferiores, como las pruebas unitarias.

Dice, no puede encontrar el texto igual a disponible, añade índice 0. Si miramos en el simulador, podemos ver por qué. La pantalla disponible no se muestra, se muestra la pantalla de inicio de sesión. ¿Por qué es eso? Estamos reiniciando la aplicación. La razón es, como probablemente la mayoría de las aplicaciones que admiten inicio de sesión, almaceno las credenciales de inicio de sesión o el token de acceso, no recuerdo cuál, en el almacenamiento local seguro en la llave, porque no quiero tener que iniciar sesión cada vez que lanzo la aplicación, por supuesto. Y entonces cuando Detox está ejecutando la aplicación, ese almacenamiento local o almacenamiento de llave también se almacena. Así que ese es un estado que persiste de prueba a prueba. Si terminas la prueba anterior iniciada sesión, estarás iniciado sesión al comienzo de la siguiente, o si has estado jugando con el simulador y es el mismo simulador que usas para el desarrollo local, o si Appium está reutilizando un simulador de otra persona, o de otra prueba ejecutada por alguien en tu organización, el estado de él puede ser impredecible. Y entonces hay algunas formas diferentes de abordar eso cuando estás escribiendo pruebas de detox. Por el bien del inicio, vamos a ver algunas formas más complejas en la siguiente prueba. Pero por el bien de la prueba de inicio, yo estaba como, hombre, no quiero lidiar con eso. Como solo quiero saber que la aplicación se lanzó. Y entonces lo que encontré fue el elemento de navegación acerca de en realidad muestra si estás iniciado sesión o no. Acerca de está aquí ahora. Así que probemos eso. y mostrará que pasa en ambos casos. Así que estamos buscando el botón de navegación acerca de, y cuando estamos desconectados, aparece y pasa. ¿Y qué pasa cuando estamos iniciados sesión? Ejecuta la prueba de nuevo. Aparece, y el acerca de está allí en la barra lateral de nuevo, y entonces pasa. Así que hemos escrito esta prueba porque todo lo que nos importa en este punto es iniciar. Escribimos la prueba para que si hay algún estado de inicio de sesión existente o no en la llave, la prueba pase de cualquier manera. Así que eso es genial. La prueba es más robusta. El hecho de que haya estos data almacenados es un poco desafortunado, aunque, porque tengo que recordar tener en cuenta eso. Podría escribir una prueba en el futuro, y funciona bien para mí localmente y tal vez funciona bien en CI también. Pero alguien más que está haciendo algo diferente en su simulador local, falla para ellos. Así que ese es un posible caso de consistencia de testing que es difícil de evitar. Probablemente hay otros enfoques para restablecer la llave y cosas así localmente, pero solo quería dar esta ilustración. Así que ese es uno de los pocos ejemplos diferentes que veremos en la masterclass hoy de tener que abordar algo de esta complejidad del estado compartido en nuestras pruebas de detox. Pero esa es nuestra prueba de inicio. Déjame revisar mis notas para ver si hay algo que olvidé decir sobre eso. Sí, estamos listos para pasar al siguiente. Así que la segunda prueba, y estos no son nombres oficiales para categorías de pruebas, pero llamé a esto una prueba de juego. Y solo estoy confirmando que debería mostrar las tareas pendientes. Pasemos por alto esto de inicio de sesión por un momento ahora, y veamos si puedes seguir leyendo la prueba con lo que está sucediendo. Vamos a iniciar sesión. Vamos a confirmar que el texto no tienes tareas pendientes disponibles, buen trabajo, aparece. Así que eso confirma que estamos viendo el estado inicial de las cosas. Voy a seguir manualmente estos pasos para que puedas verlo al lado de aquí. Luego voy a ir al campo de nuevo nombre de tarea pendiente y escribir limpiar el escritorio de la oficina. Presiono la tecla de retorno. Ahora estoy confirmando que ese campo de texto está vacío, pero que el texto aparece en la página. Eso confirma que se ha mostrado allí. Vamos a hacer clic en él. Vamos a editarlo. Vamos a hacer clic en el campo de nombre y tocar de nuevo para limpiar ese escritorio de la oficina una y otra vez. Voy a hacer clic en el botón de guardar dos veces. Dos veces. Vamos a tener que hablar de eso en un segundo. Eso es otra cosa que tenemos que tener en cuenta, pero solo voy a hacer clic aquí una vez. Así que limpiar el escritorio de la oficina muestra que nos aseguramos de que el botón de guardar desaparezca y nos aseguramos de que el texto actualizado se muestre en la pantalla. Así que eso no es un flujo de trabajo completo para un usuario, pero es solo como, creo que si estás testing manualmente, eres como, bueno, déjame asegurarme de que las cosas básicas están funcionando. Eso es más o menos lo que hago cuando he actualizado React Navigation y quiero probarlo manualmente para asegurarme de que todo se muestra bien, como solo hago clic en algunas cosas, como hago algunas de las cosas básicas que hace el usuario, y entonces ahora he visto varias pantallas, varias operaciones, he cubierto algunos de los conceptos básicos de la aplicación. Así que esto es como el siguiente peldaño en la escalera en términos de complejidad de la prueba. Testing más que solo algo que se muestra en la pantalla que algo de la lógica de tu aplicación realmente funciona. Eso es un aumento en tu nivel de confianza. Así que corramos la prueba ahora y veamos cómo se ve. Puedo ejecutar estas pruebas individualmente. Los archivos individualmente. Y para la prueba de extremo a extremo, a menudo lo tengo de esta manera donde es solo una prueba por prueba archivo porque esas tienden a ser lo suficientemente largas ya. Así que corramos esta prueba. Voy a tratar de narrar rápidamente mientras está sucediendo. Oh, sí, tenemos que ver la cosa de inicio de sesión también. Te lo mostraré en un segundo. Así que iniciamos sesión, ingresamos una tarea pendiente, la ingresamos, la sacamos, la editamos y la guardamos. El final, la prueba ha pasado. Así que ha confirmado que todas esas cosas sucedieron. Así que esta es una prueba de detox un poco más sustancial. Acabo de notar, notar que dice aquí creado indefinido. Así que aquí es donde un campo de fecha es. Recordarás, así que el servidor en realidad establece la fecha en que se creó algo. Recordarás en nuestro módulo de API falso o simulado allí que no hice ninguna configuración de campos de fecha. Fue porque la aplicación no explotó sin él. Y entonces no me molesté porque soy muy perezoso. Y solo quería hacer una conexión, como configurar testing es mucho trabajo. Y entonces está bien ser un poco perezoso donde puedas, porque si te mantienes a un estándar de perfección, puede ser muy desalen

18. Manejo de inicio de sesión y teclado virtual

Short description:

Para asegurar un punto de partida consistente, la prueba verifica si el botón de inicio de sesión está presente. Si se encuentra, hace clic en el interruptor de navegación y el botón de inicio para cerrar la sesión. Luego, inicia sesión para establecer un punto de partida consistente. La prueba pasa independientemente del estado inicial del simulador. La prueba maneja la posibilidad de estados de inicio y cierre de sesión, asegurando la sincronización al inicio. Se utiliza el enfoque multitap para manejar el comportamiento del teclado virtual. La prueba está escrita para manejar ambos escenarios, descartando el teclado y tocando el botón. Este ejemplo destaca los desafíos que pueden surgir en las pruebas de extremo a extremo, especialmente en dispositivos móviles. La prueba demuestra la flexibilidad requerida para manejar diferentes estados y variaciones en simuladores y emuladores. La prueba de juego es seguida por la prueba de camino feliz, que involucra los mismos pasos de configuración e inicio de sesión.

prueba el flujo de inicio de sesión. Y básicamente si el botón de inicio de sesión no se encuentra, eso significa que estás registrado. Entonces, lo que hago es hacer clic en el interruptor de navegación y luego hago clic en el botón de inicio para asegurarme de que estamos desconectados. Podría ejecutar esta afirmación de nuevo solo para asegurarme después, pero básicamente es como, oh sí, si el botón de inicio de sesión está presente, ya estamos desconectados, genial. De lo contrario, asegúrate de que estamos desconectados y luego desde allí, llegamos a un punto de partida consistente donde estamos desconectados. Y luego desde allí, seguimos adelante e iniciamos sesión desde allí. Eso nos da un punto de partida consistente. Veamos que sucede de ambas maneras. Así que empiezo desde desconectado. Ejecuto la prueba. Y luego inicio sesión. Incidentalmente, es posible que notes que no escribo un nombre de usuario y una contraseña. El mock que configuré para el punto final de inicio de sesión no está comprobando eso. Así que puedo hacer clic en iniciar sesión y estoy listo para ir. Es suficiente para la prueba que tengo ahora. Así que esa prueba pasó cuando empezamos desconectados. Ahora estamos iniciados sesión para empezar. Ejecutémoslo y asegurémonos de que funciona. Aparece, sacamos la navegación y cerramos sesión y luego volvemos a iniciar sesión de nuevo y la prueba se va. De cualquier manera, cualquiera que sea el estado existente del simulador, nuestra prueba puede pasar.

Ahora, podrías preguntar, ¿por qué cerraste sesión y luego volviste a iniciar sesión? Podría haber escrito esto de la manera opuesta para decir, oye, si se encuentra el botón de inicio de sesión, inicia sesión, de lo contrario no hagas nada, y no es muy diferente. Esto solo se inclina un poco más hacia el lado de, asegúrate de pasar por el flujo de inicio de sesión también también. Tal vez haces eso para una prueba y luego para otras pruebas dices, no te preocupes por eso. Si estoy registrado, estoy listo para ir. Esto tiene el mismo desafío que decía antes sobre la posible sesión de inicio y el estado de cierre de sesión con la verificación allí, donde es como localmente, si te olvidas de poner esto, todo podría funcionar bien y luego podría romperse para otra persona o romperse en CI. Así que eso es solo una de las cosas desafortunadas de tener este estado persistente es que tienes que recordar sincronizar tus pruebas al inicio. Además, si vas a poner esto en todas tus pruebas, vas a ver esto en otras pruebas. Puedes ponerlo en una función de ayuda y reutilizarlo en todo tu conjunto de pruebas. No lo hice aquí solo para que fuera fácil de ver en línea para que pudieras verlo, pero eso es una cosa que manejamos. ¿Qué pasa con esta cosa de multitap aquí? En realidad no escribí el código en su lugar aquí. Permíteme hacerlo sin el multitap para que puedas verlo fallar porque el botón de inicio de sesión solo necesita un toque una vez. Así que intentemos ejecutar la prueba de esta manera donde toco el botón de inicio de sesión una vez. Y notarás que tengo un comentario aquí. El primer toque descarta el teclado si se muestra. Así que ejecutemos la prueba y asegurémonos de que pasa aquí con un solo toque. Toma un poco para empezar. Eso es lo que dije sobre la velocidad de la prueba de extremo a extremo. Gran conjunto. Haz clic en guardar. Ahora es posible que hayas notado que el teclado virtual del iPhone en pantalla no apareció. Veamos qué sucede cuando aparece. Así que en el simulador, ¿cuál es ese atajo de teclado? Teclado, conectar duro. Ahí vamos. Bueno, ahora lo he configurado para que aparezca el teclado de software, porque está simulando el hecho de que no hay un teclado de hardware conectado. Ejecutemos esa prueba con un solo toque de nuevo. Así que no estoy seguro si viste, no lo hice cola por adelantado, pero cuando tocamos el botón de guardar, lo que sucedió fue que puedo mostrarte aquí. Entonces, cuando se muestra el teclado virtual en pantalla, y toco el botón de guardar, lo que sucede es que el teclado se descarta, pero el botón de guardar no recibe realmente el toque. Tengo que tocar una segunda vez para que se registre. Ahora, no estoy seguro si esto viene de iOS o React Native o React Native Paper, que es la biblioteca de UI que estoy usando. Desde el punto de vista del usuario, tiene sentido. Me gusta, quiero poder hacer clic fuera de este campo para descartar el teclado, así que eso es muy útil. Pero por el bien de la prueba de automation, se vuelve un poco no determinista. Así que jugué un rato para encontrar enfoques aquí. Y lo que encontré, de nuevo, al igual que hemos estado haciendo para el inicio de sesión, es como, ¿hay una manera en que puedo escribir esta prueba que manejará cualquiera de los dos estados en los que estamos? Así que lo que encontré fue que multitap2 para tocar dos veces descartará con éxito el teclado y luego tocará el botón cuando se muestra el teclado virtual. Y si no se muestra, el segundo toque simplemente se ignora, como funciona bien. Podría guardarlo en el servidor dos veces, pero si es así, sería bueno aprender para eliminar esa causa de información duplicada en tu aplicación. Así que veamos el multitap funcionando ahora. Ahora que hemos mostrado el teclado virtual. Y este es solo un ejemplo del tipo de escamas que pueden surgir en las pruebas de extremo a extremo, especialmente en móviles. Como hay desafíos que surgen que necesitas abordar. Teclado virtual mostrado. Aparece el teclado virtual. Toca y toca. Y tocó muy rápido, por lo que no viste los dos suceder en secuencia. pero sí viste que el teclado fue descartado y el botón de hecho se registró. Ahora veamos qué sucede si lo configuramos. Hombre, estos golpes de teclado son... Sí, no conozco el atajo de teclado. Conectar teclado de hardware. Ahí vamos. Sí. Bueno. El teclado de hardware está ahí, así que cuando hago clic, no veo el teclado de software. Así que ejecutemos la misma prueba y asegurémonos de que multitap2 ¿Cómo sabes que funciona en este caso también? Sí, funcionó. Así que eso no resultó en un error por múltiples toques o algo así. Y así fue como escribí la prueba que funciona sin importar en qué situación se encuentre. Es posible que no te encuentres con esta situación en tus aplicaciones, pero apuesto a que te encontrarás con algo en en tus aplicaciones en cuanto a diferentes estados en los que pueden estar los simuladores y emuladores, y tendrás necesidad de encontrar formas de solucionarlo. Es parte del desafío de las pruebas de extremo a extremo. No viene en React Native Testing Library porque eso solo está trabajando con el JSX. No está realmente trabajando a través de toda la pila. No está realmente corriendo en un dispositivo. Así que el realismo disminuye nuestra confianza, y tenemos que mitigar algunas de estas variaciones que pueden suceder. Así que eso fue solo de pasada, pero esa es nuestra prueba de juego. Ahora, esta próxima prueba se llama camino feliz. Así que echemos un vistazo a eso y veamos qué implica. Así que tenemos las mismas cosas de configuración. Tenemos las mismas cosas de configuración de inicio de sesión. Y entonces, lo que vamos a hacer, voy a seguir aquí. Voy a. Bueno, déjame reiniciar para tener ese comienzo fresco de nuevo. Me pregunto si necesito conectar.

19. Prueba de Camino Feliz y Dependencias de Pruebas

Short description:

En esta prueba de camino feliz, pasamos por todo un flujo de trabajo de usuario, creando una tarea pendiente, editándola, completándola y eliminándola. Representa un flujo de usuario razonable de principio a fin. Las pruebas de extremo a extremo son eficientes para probar flujos de usuario completos, ya que proporcionan un estado en progreso y permiten una fácil navegación. La prueba de camino feliz es un superconjunto de la prueba de juego, cubriendo los mismos pasos y yendo más allá con la finalización y eliminación. Si se debe mantener la prueba de juego depende de factores como la longitud y complejidad de la aplicación y la necesidad de una retroalimentación más rápida. Si la prueba de juego no es necesaria, se puede eliminar para reducir el conjunto de pruebas. Es importante que las pruebas de extremo a extremo tengan un comienzo limpio y no dependan de otras pruebas para el inicio de sesión o la configuración. La prueba de camino feliz es autónoma y aislada, asegurando que puede funcionar correctamente independientemente de otras pruebas. Se recomienda evitar las dependencias entre pruebas y que cada prueba realice la configuración necesaria de forma independiente.

oh necesito no recargar eso es correcto estaba usando el atajo de teclado para recargar expo pero como esta es la versión de lanzamiento de mi aplicación que estoy ejecutando contra detox aunque todavía se está ejecutando el simulador no tiene los mismos atajos creo que hay ¿hay un movimiento? no, para tener un comienzo limpio voy a forzar la salida y empezar de nuevo. ¿Es esto eso? Sí, OK, genial. Bien, tengo tengo un comienzo limpio. Así que déjame seguir manualmente esta prueba de camino feliz para que puedas verla. Voy a decir crear. No, quiero el teclado de hardware. Crear un escritorio de oficina limpio. Y vuelvo para asegurarme de que aparece en la lista. Eso es en realidad algo que sucedió en la otra prueba también. Hablaremos más sobre eso después. Ahora lo estoy editando. Hago clic en él. Hago clic en Editar. Campo de nombre. Vuelvo a tocar. Hago clic en Guardar. De nuevo, eso es lo mismo que hicimos en la otra prueba, pero ahora seguimos adelante. Así que ahora hago clic en Completar. Confirmo que el escritorio de oficina limpio no es visible. Luego voy a la pestaña Completado, y confirmo que es visible allí. Ahora, solo como recordatorio, esto se está ejecutando a través de nuestro servidor de aplicaciones falso. Así que cuando hago mi construcción de Detox, está configurado. Oh, no te mostré eso en las instrucciones. Déjame mostrarte eso. Eso está en el sitio de React Testing IOS. En mi configuración de detox, cuando configuro una aplicación iOS para su lanzamiento, pongo export mock API equals true al principio. Y estoy usando EAS build porque eso es lo que estoy usando para Expo. Así que cuando he configurado Expo para construir mi aplicación, estoy pasando mock API. Así que estamos usando el backend simulado. Así que a medida que avanzamos por todos estos pasos, estamos confiando en ese backend simulado para crear elementos, actualizarlos, cambiar qué consultas, en qué pantallas vuelven. Y eso es lo que hace que todo esto funcione, aunque no tengo una API de backend en ejecución y me estaba dando un comienzo fresco en cada prueba. Así que porque hemos configurado esa capa de simulación, puedo simplemente no pensar en eso. Y puedo escribir las pruebas que quiero escribir para llegar hasta el final de mi aplicación. Así que volviendo de ese monólogo, he completado mi tarea pendiente y he listado eliminar aquí también. Así que hago clic en CleanOfficeDesk de nuevo. Hago clic en Eliminar. Y compruebo que la tarea pendiente no es visible. Y luego cuando voy a la lista de eliminados, confirmo que la tarea pendiente está allí. Así que vamos a ejecutar esto para asegurarnos de que funciona en la prueba real en ejecución, no solo como instrucciones para mí como humano. Ejecuta la prueba de camino feliz. Evita la tentación de comentar mientras avanzamos. Oh, comentaré lo que está haciendo la prueba. Creamos una tarea pendiente. La tocamos. La editamos, la guardamos, confirmamos que aparece. Oh, sí, la completamos. Aparece en la lista de completados, y luego hacemos clic en eliminar, y luego nos aseguramos de que aparece en la lista de eliminados, y hemos terminado. Así que hablemos un poco sobre lo que está pasando en esta prueba de camino feliz. Realmente estamos pasando por todo un flujo de trabajo de usuario. Este es un ejemplo que se me ocurre, de una secuencia que alguien podría seguir en su lista de tareas pendientes para llegar a la finalización. No siempre elimino mis tareas pendientes completadas. Simplemente las coloca en una pantalla diferente, pero parecía natural agregar eso también. Crear una tarea pendiente, editarla, completarla y eliminarla. Es un flujo de usuario de camino feliz razonable. Lleva al usuario a través del inicio de un flujo de trabajo hasta el final. Y eso es una de las cosas que mencioné es un beneficio y una gran manera de usar las pruebas de extremo a extremo. Parcialmente porque son lentas, a menudo es más eficiente ejecutar un flujo de usuario completo. Y porque tienen ese estado en progreso, es una forma fácil de llegar a donde necesitas ir. Así que a menudo es el caso de que en una prueba de extremo a extremo, quieras probar a través de todo un flujo de usuario. Tuvimos pruebas más abreviadas para el arranque y el juego. Um, pero a menudo es beneficioso ir allí. Ahora otra cosa a tener en cuenta es que esta prueba de camino feliz es un sub es un superconjunto de la prueba de juego. Quiero decir, creo que si comparo los archivos, serían literalmente los mismos. Y sé que copié y pegué los archivos cuando los creé. Nosotros, nosotros iniciamos sesión creamos una tarea pendiente y editamos una tarea pendiente eso es idéntico. Luego la prueba de camino feliz va más allá para completar y para eliminar. Entonces, la pregunta es, ¿debería mantener la prueba de juego o no? Como tantas cosas en las pruebas, puedes tomar tu propia decisión. Entonces, si generalmente – si solo estás pensando en ejecutar todo tu conjunto de pruebas, podrías decir, hey, la prueba de camino feliz lo cubre, y por lo tanto no necesito la prueba de juego más. Tal vez fue útil por un tiempo, pero una vez que escribiste una prueba que fue más allá, tal vez ya no sea necesaria, especialmente porque solo está jugando. No está simulando un flujo específico. Por otro lado, tener una prueba más corta puede ser útil para otros propósitos. Tal vez tu prueba de camino feliz es bastante larga porque es una aplicación complicada con muchos pasos, y entonces tal vez un poco de una prueba de juego te permitirá simplemente ejecutar algo rápido localmente. Tal vez en las solicitudes de extracción, solo quieres ejecutar las pruebas de juego, no las pruebas de camino feliz y otras pruebas más largas para obtener una retroalimentación más rápida, así que si encuentras que es útil tener la prueba de juego, para darte una retroalimentación más rá

20. Prueba de Características Secundarias y Aislamiento

Short description:

La ejecución de pruebas en aislamiento es beneficiosa para los desarrolladores, especialmente cuando se trata de suites de pruebas largas. Permite una identificación y resolución más rápida de las pruebas fallidas. En la prueba de características secundarias, el enfoque está en aplazar las tareas pendientes. La prueba asegura que las tareas pendientes se pueden aplazar para el futuro y aún aparecen en las listas correctas. Además, se prueba la finalización de las tareas pendientes para asegurar que funciona correctamente. Al separar las características secundarias en sus propias pruebas, los desarrolladores tienen la flexibilidad de ejecutar pruebas específicas o la suite de pruebas completa según sea necesario.

Y luego, si necesitan configurarse en un estado similar al de otras pruebas, podrías compartir el código. De nuevo, podrías poner este conjunto de código en lugar de copiarlo y pegarlo. Podrías ponerlo en una función auxiliar que se llame desde varios lugares. Pero creo que tener estas pruebas que puedan ejecutarse en aislamiento realmente funciona mejor para muchos flujos de trabajo de desarrolladores. Ahora, las cosas pueden ser diferentes para los automatizadores de pruebas profesionales que trabajan en un departamento de QA. Si para ellos, tener una secuencia de pruebas de extremo a extremo funciona mejor, tienen su propia forma de abordar las cosas. Y lo respeto totalmente. Pero lo que he encontrado como desarrollador y en círculos de desarrolladores, leyendo recursos como patrones de pruebas X-unit, generalmente los beneficios de estas pruebas que pueden ejecutarse independientemente son muy útiles. Y una de las razones clave es lo que sucede cuando tienes una suite de pruebas larga, una suite de pruebas de una hora, y una prueba en el minuto 55 falla. Pero cuando la ejecutas en aislamiento, tiene éxito. Eso es un lugar difícil de estar porque ahora tienes que esperar 55 minutos para reproducir las pruebas fallidas. Y cada vez que intentas cambiar algo para que pase, son otros 55 minutos para ir. O hay un esfuerzo extenso que tienes que hacer para ver, OK, ¿cuál es el punto de partida necesario de esta prueba? ¿Cuáles de estas cosas anteriores puedo descartar y saltar y cuáles necesitan estar allí? Tal vez cuatro pruebas diferentes necesitan ejecutarse en secuencia para que esta funcione. Esa es la clase de dependencia que no quieres tener en tu suite de pruebas porque eso es algunas de las cosas que pueden hacerlas una pesadilla para trabajar con y por eso definitivamente recomiendo en pruebas llegar al punto donde pueden funcionar perfectamente en aislamiento o como parte de tu suite de pruebas completa eso es lo que he encontrado que funciona para mí así que gracias por la pregunta James bien con esto vamos a ver esta prueba de características secundarias y déjame mostrar los detalles y luego hablar sobre el concepto de nuevo camino feliz fue eso es generalmente un término que se entiende como hey, el camino donde todo tiene éxito. Así que no estoy testing todos los diferentes escenarios de error para aquí. Estoy testing solo cuando tienen éxito. Puedes recordar en nuestra API falsa, en realidad no simulé los errores que han ocurrido. Eso es algo más que puedes hacer también. Puedes codificarlo donde es como, oh, si paso este nombre de tarea pendiente, el nombre de la tarea pendiente podría ser simular error, entonces devolvería un error del servidor, como diciendo que el servidor estaba caído o algo así. Así que esa puede ser una forma en tus falsificaciones de simular errores. Pero aquí llamo a esto secundario y veamos qué está involucrado allí. Dije, debería permitir aplazar las tareas pendientes es el nombre de la prueba que puse en marcha. Así que tenemos el típico inicio de sesión, de nuevo configurando esta prueba para poder ejecutarse en aislamiento. Y desde aquí, vamos a repasarla de nuevo. Voy a forzar la salida y simplemente obtener mi nuevo inicio en una prueba aquí. Voy a crear ese escritorio de oficina limpio. Es lo único en mi mente cuando escribí estas pruebas. Ahora, lo siguiente que hago es aplazar hasta mañana. Hago clic en aplazar un día. Observa que uso el ID aquí, botón de aplazar un día. Así que esto es una especie de nota. Si quisiera usar el texto para encontrar este botón, el texto varía dependiendo del día en que esté. Eso es otra cosa que puede cambiar. Eso es realista en tus pruebas. Sin embargo, eso puede llevar a pruebas que tienen éxito un día de la semana y fallan los otros. En este caso, simplemente encuentro el botón por ID porque eso no varía. Así que aplazo por un día. Me aseguro de que la tarea pendiente no es visible. Y luego voy a la lista de mañana. y me aseguro de que esta tarea está allí luego la aplazo hasta más adelante en el futuro cuando ¿probé lo correcto? no sé si toqué eso demasiado rápido no estoy seguro nuestras pruebas se ejecutarán en un minuto para asegurarse de que está bien así que la aplacé de nuevo así que es ya no está en la página de mañana sino en la página de futuro oh sí algo está algo veo creo que creo que golpeé completo o algo así si estás viendo la uh la, sí, supongo que golpeé eliminado accidentalmente. Comienza con una D. Eso no fue un buen diseño de UX en mi código. Déjame pasar por eso una vez más. Inicia la aplicación. Limpia el escritorio de Oculus. Ábrelo. Aplaza un día. Aparece en la lista de mañana. Y ahora hago clic en él. Aplaza otro día. Ahora no muestra en la lista de mañana, pero sí muestra en la lista de futuro. También observa aquí, Um, en la lista. Comprobé para asegurarme de que te muestra allí realmente para probar completamente debería confirmar que aparece bajo el viernes en esa lista. Um, Pero eso requeriría simular o saber en qué día estamos. Y así decidí no hacer eso. Eso es algo que pruebo en el nivel de unidad nivel de pruebas de componentes, Pero no lo pruebo aquí y en realidad agrupar estas tareas pendientes es algo que escribí en JavaScript puro. Me llevó un tiempo hacerlo y tuve que cambiarlo a medida que cambiaba lo que quería hacer y es algo que es muy dinámico. Así que escribí algunas pruebas unitarias que ni siquiera ejecutan componentes para que eso funcione. Luego obtengo una estructura de data de eso y la muestro en la pantalla. Hago eso en otra aplicación. No estoy seguro de si probé la unidad en esta aplicación así que no tengo un ejemplo a mano. Pero ese es un ejemplo de cuando puede ser más robusto hacer eso en una prueba unitaria. Porque en una prueba unitaria puedes controlar las fechas que se pasan. Mientras que aquí cuando creo un nuevo registro, no puedo controlar la fecha porque estoy en el escenario de prueba de extremo a extremo más realista. Se trata de la pirámide de pruebas y de averiguar la mezcla de enfoques de prueba que funcionan para ti. Y luego aquí todavía tengo la finalización al final. No sé por qué. Simplemente decidí que sería bueno tenerlo porque en última instancia quieres completar las tareas pendientes. Así que quería asegurarme de que incluso si estoy aplazando las tareas pendientes, de hecho puedo completarlas al final. Y me aseguro de que desaparezca de esa pantalla y aparezca en la lista de completados. Bien, así que vamos a ejecutar esa prueba y asegurarnos de que funciona. Y el concepto de esto con una característica secundaria es que hay una prioridad allí. Mi aplicación es gratuita. No gano dinero con ella porque así es como manejo mi negocio, mis cosas secundarias. Quiero decir, es una lista de tareas pendientes. Por el amor de Dios, ¿quién necesita otra aplicación de lista de tareas pendientes? ¿Quién me va a pagar dinero por eso? Pero decidí que, hey, el camino feliz es que quiero poder completar las tareas pendientes. Eso es lo más importante en una aplicación de lista de tareas pendientes. Ahora, aplazar es secundario. Si aplazar estaba roto, los usuarios lo reportarían y querrían que funcionara. Pero la finalización es lo más importante. Solo voy a probar una cosa en una prueba, va a ser completar las tareas pendientes que he hecho aquí y tiré en eliminar por si acaso. Pero pasar por aplazar fue algo que quería considerar secundario. No quería incluir eso en la misma prueba, pero sí quería alguna cobertura allí. Como una característica secundaria, esto es también algo importante que yo q

21. Decidiendo la Cobertura de Pruebas con Detox

Short description:

Estos son algunos ejemplos de tipos de pruebas de Detox que puedes escribir, como pruebas de arranque, pruebas de exploración, flujos de camino feliz y caminos felices de características secundarias. La decisión de cuántas pruebas escribir depende de factores como la inestabilidad, la velocidad de las pruebas, la facilidad de escritura y las necesidades específicas de tu aplicación. Comienza pequeño, ve lo que funciona y haz cambios en consecuencia. Las pruebas de extremo a extremo en React Native no son tan sofisticadas como en la web, así que date tiempo para navegar y encontrar el equilibrio adecuado para tu equipo.

pruebas. Pero ese fue mi proceso de pensamiento por el cual incluí la finalización aquí también. Es una especie de buena manera de documentar las cosas esenciales que un usuario quiere hacer al aplazar las tareas pendientes. Tal vez en el futuro decidiría eliminar la finalización de esa pantalla, porque no estaba pensando que tener una prueba de extremo a extremo confirma que ese flujo puede funcionar. Muy bien, eso ha sido mucho código, así que volvamos y miremos más a nivel conceptual las categorías de pruebas de las que hemos hablado juntos. Estos son algunos ejemplos de tipos de pruebas de Detox que puedes escribir. Estas no son categorías rígidas. Nadie ha publicado un libro o un post en un blog enumerando estas categorías. Simplemente, mientras pensaba en cuál es la fruta de menor alcance y cuál es el mínimo que puedo escribir para obtener algún tipo de beneficio, estas son las categorías que me vinieron a la mente. Espero que te inspire a pensar en categorías similares para ti. Puedes tener una prueba de arranque. A veces esto se llama la prueba de humo. Actualmente me estoy metiendo en las computadoras vintage, y usan el término prueba de humo muy literalmente. Como he estado jugando con estos componentes antes de poner cualquier esfuerzo para volver a armar esta computadora. Voy a enchufarla, encenderla, y todo lo que quiero asegurarme es que no aparece humo. En mi reunión local de computadoras vintage, apareció humo cuando alguien encendió su Apple II. Y así como eso es lo primero a probar. Como antes de hacer cualquier otra cosa, vamos a comprobar rápidamente si hay humo. Y para una aplicación móvil, Afortunadamente, aparte de algunos iPhones más antiguos, fumar, explotar tal vez algunos Samsungs, el humo no suele ser algo común, pero estamos simplemente testing como ¿arranca la aplicación en absoluto? La prueba más básica. No quería compartir ese ejemplo. Esa es una especie de paralelismo divertido allí. Estos términos tienen una historia. A continuación está una prueba de exploración. Simplemente haz algunas cosas en la aplicación. ¿puedo usar algunas de las cosas que la aplicación me permite hacer? Tocando al azar simplemente para darle una prueba, solo para ver si las cosas parecen estar funcionando, lo que simula exactamente lo que hago cuando quiero probar manualmente una dependencia localmente. Luego tienes la característica más importante que genera dinero, el flujo de camino feliz. Ya sabes, es lo más importante. Como, ¿cuál es la cosa que mis usuarios o mi CFO o mis capitalistas de riesgo van a estar más molestos si deja de funcionar en la aplicación. Mientras esta única cosa esté funcionando, la mayor crisis ha sido evitada. Tener una prueba de extremo a extremo para cubrir eso, incluso si es tu única prueba de extremo a extremo, añade mucho valor. Y luego de ahí, puedes ir a las características secundarias, caminos felices. Ten en cuenta que, de nuevo, estoy enumerando todas estas como caminos felices, no como pruebas de error. Podría tener sentido probar un escenario de error en las pruebas de extremo a extremo, pero no probaría cada escenario de error. Creo que si tienes buenas pruebas de componentes, pueden cubrir muy fácilmente esos escenarios de error, y esos son simplemente difíciles de encajar en un flujo de características como usuario. Quiero decir, es un poco difícil configurar tu API falsa para devolver errores en algunos escenarios y no en otros. Mientras que en una prueba de componentes, como he hablado en transmisiones en vivo y en mi masterclass del año pasado, las pruebas de componentes como React Native Testing Library son muy simples. Estamos construyendo esto en mi actual cliente ahora mismo. Unit testing nuestro código, unit testing nuestros hooks, unit testing nuestros componentes, Y en cada uno simulamos cuando el servidor da errores, cuando el servidor tiene éxito y las cosas son diferentes tipos de errores. Así que eso es muy fácil a nivel de pruebas de componentes. Me quedaría con los caminos felices para las pruebas de extremo a extremo para las pruebas de Detox. Entonces, ¿cómo decides cuántas de estas escribir? ¿Solo haces una prueba de arranque? ¿Escribes pruebas para muchas de tus características secundarias? Aquí están algunos de los factores para tu aplicación que puedes usar para pensar en ello. Primero, la inestabilidad. Cuanto más inestables sean tus pruebas, menos pruebas querrás y es mejor que sean más cortas. Ahora, no te culpo por las pruebas inestables. Siempre va a haber algo de inestabilidad, parece, en las pruebas de extremo a extremo. Es muy difícil de evitar. Y así como estás probando cosas, dependiendo de tu aplicación, dependiendo de tu código, dependiendo de cuántas animaciones o cuánta complejidad haya, puedes experimentar más o menos inestabilidad. Si encuentras que estás experimentando mucha inestabilidad, comienza pequeño, comienza con menos pruebas y pruebas más cortas. Espera a que se ejecuten de manera fiable antes de empezar a escribir más o pruebas más sofisticadas. También, la velocidad de las pruebas. Cuanto más lentas sean tus pruebas, menos pruebas querrás, y las pruebas deberían ser más cortas. Tus pruebas pueden ser lentas debido al hardware en el que se están ejecutando. Tus pruebas pueden ser lentas porque tus flujos son muy complejos, y por lo tanto hay mucho que hacer. Y así muchas características pueden afectar la velocidad de tus pruebas. Solo ve cómo funciona. y sí, si las cosas van lentas, no configures una suite de pruebas de una hora de duración para empezar. Comienza con algo pequeño y luego puedes, es como escalar la pirámide de pruebas hacia arriba o hacia abajo. No lo sé. Pero como solo averiguando y esto es todo sobre desarrollo de software ágil. Como comienza pequeño y ve a medida que avanzas como qué es doloroso y luego haz un cambio o qué deseas tener más de y luego haz un cambio. Puedes navegar esto y no necesitas saber la respuesta desde el principio. Incluso si quieres decidir más tarde, está bien, vamos a hacer una política sobre cuánta cobertura de pruebas tener. Como genial, está bien. Pero especialmente con Detox, con cualquier prueba de extremo a extremo en React Native, date un poco de tiempo. Las pruebas de extremo a extremo en React Native no son tan sofisticadas como en la web por una variedad de razones. Y así como comienza pequeño y ve lo que funciona para ti antes de decidir una política como equipo. Otro factor es la facilidad de escritura. Ya sabes, descubre para tu aplicación, como ¿es muy fácil poner pruebas de extremo a extremo juntas o tienes que hacer mucha configuración de data ¿Hay muchas de esas cosas como el multi-tap too que tuve que hacer que tienes que averiguar? Entonces, si es realmente difícil escribir estas pruebas, está bien, simplemente comienza pequeño y no te estreses. Pero si es bastante fácil escribirlas rápidamente, entonces es como, genial, adelante y escribe un número de ellas. Así es como puedes decidir en la escala móvil de cuán rápido escribir cuántas pruebas. Y solo quiero ponerlos de nuevo en la pantalla. Y eso es prácticamente todo en cuanto a decidir cuánto probar en Detox. No hay una respuesta correcta. incluso menos que en las otras categorías que estoy compartiendo hoy. Solo conoce estas herramientas que tienes en tu caja de herramientas. Pruébalas y ve lo que funciona para tu aplicación y tu organización y tu equipo.

22. Ejecutando Detox en un Servidor de Integración Continua

Short description:

Para ejecutar Detox en un servidor de integración continua, debes considerar los desafíos específicos de las aplicaciones móviles nativas. Las variaciones entre las plataformas de CI, las dependencias de versiones específicas y la lentitud son problemas comunes. Las pruebas en CI son importantes para garantizar un entorno de trabajo consistente y ejecutar pruebas regularmente. Sin embargo, debido a las complejidades involucradas, se recomienda habilitar una prueba a la vez y progresar gradualmente. A pesar de las dificultades, el ponente comparte su configuración de Detox CI en GitHub Actions como una solución. Es importante tener en cuenta que la ejecución de Detox en CI no está garantizada y puede variar dependiendo de la plataforma y la infraestructura.

Esa es la forma de pensar en cuántos tipos diferentes de pruebas de Detox escribir. Una breve cosa que quería mencionar antes de continuar es solo recordarte, esta es la página de inicio de la masterclass con enlaces a todas las cosas que hemos estado cubriendo y publicaremos el video de la masterclass después en un par de semanas una vez que Git Nation haya tenido tiempo para procesarlo y subirlo a su sitio web. Quería recordarte que seguramente la aplicación que hemos estado revisando durante las últimas secciones es de código abierto. Y así, si sigues este enlace, llegarás al repositorio. Estas son algunas instrucciones específicamente relacionadas con la masterclass en caso de que quieras probarlo. Pero esta es la aplicación. Está ahí y aquí es donde la mantengo. Y así puedes descargar esto y puedes probar estas pruebas tú mismo. Y así, digamos que estás teniendo un conjunto de Detox Y así hay una especie de obstáculo para superar para que eso funcione. Puedes probar Shirley localmente. Intenta ejecutar estas pruebas de extremo a extremo y puedes ajustarlas. Puedes hacer sugerencias para las pruebas que querías agregar si quieres, pero puedes probar cosas. Y ni siquiera necesitas ejecutar mi backend porque tenemos la API simulada configurada. Así que para tu ejecución en desarrollo, así como para tu testing, puedes probarlo. Entonces, si descargas Shirley y lo pruebas, no dudes en comunicarte conmigo si tienes alguna pregunta. Estoy feliz de ayudar si eso ayuda con tu proceso de aprendizaje. Así que hablemos durante este tramo final aquí. Vamos a hablar durante el último segmento. Esta es una de las últimas piezas clave para configurar Detox y realmente hacer que funcione para ti. Hay una sección cinco que creo que tendremos tiempo solo para mencionar brevemente. Y eso fue una especie de sección de tramo final de todos modos. Pero esta es la última sección clave para ejecutar Detox en un servidor de integración continua. Entonces, si las pruebas funcionan para ti localmente, eso es genial. pero hay muchas razones por las que tener una integración continua es muy importante. Y por eso estoy tan contento de que sea tan prevalente en nuestra industria ahora. Si no funciona en la máquina de otra persona, no sabes cuyo entorno está roto. Entonces, el servidor de integración continua es la única fuente de verdad. Si funciona, es un entorno de trabajo comprobado. Y si se rompe, quieres que vuelva a funcionar. Así que te saca de, no funciona en mi máquina. Sí funciona en mi máquina. También asegura que las pruebas se ejecuten regularmente. Entonces, es posible que no pienses en ejecutarlas todas localmente. Tal vez lo intentas. Tal vez estableces una política de que quieres hacerlo, pero tenerlas ejecutando en un servidor de CI, especialmente cuanto más largo sea tu suite de extremo a extremo, necesitas realmente mucho tiempo. Tener CI para ejecutar eso ayuda. Y con, quiero decir, al menos si estás ejecutando en CI de la manera en que lo estoy haciendo, cuando te muestro que lo haces en un segundo, lleva bastante tiempo, y lo veremos. Entonces, la mala noticia sobre esto es que la integración continua para las aplicaciones móviles nativas es difícil. Digo específicamente aplicaciones móviles nativas en lugar de React Native porque no es específico para React Native. Entonces, la última consultoría en la que trabajé se llamaba Bignorant Ranch. Hacen una tonelada de consultoría y enseñanza de iOS y Android. Y así, para esos expertos en desarrollo móvil, simplemente reconocieron que tenían tantos problemas en CI. Como si lo hubieras hecho funcionar para un proyecto en una plataforma y luego lo haces todo de nuevo. O cuando algo se actualiza, las cosas se rompen. Entonces, sí, hablemos de por qué la CI de las aplicaciones móviles nativas siempre es mucho más difícil que en la web. Número uno, variaciones entre las plataformas de CI. Entonces, GitHub, Bitrise, GitLab, CircleCI. Los errores que obtienes en estas plataformas de CI y las soluciones que tienes que hacer son diferentes entre diferentes plataformas. Entonces, en realidad, he conseguido que Detox funcione en GitHub Actions, pero eso no necesariamente te ayudará para Bitrise. Entonces, ya sabes, sí, no hay una solución que se ajuste a todos, desafortunadamente. También dependencias de detalles de versiones específicas. acciones. Oh, hay un insecto apestoso en mi habitación. Eso es gracioso. Eso es algo que tenemos en Georgia. Espero que no apeste la habitación. Entonces, por ejemplo, en GitHub Actions, descubrí que Detox funciona para mí en macOS 12, pero se agota el tiempo en macOS 13. No tengo más detalles. Solo probé esto de nuevo hace unas semanas ahora que macOS 14 está fuera. Simplemente obtengo un tiempo de espera. No sé. No valía la pena actualizar y así que simplemente lo mantuve ejecutándose en Mac OS 12. Entonces, este tipo de cosas pueden ser difíciles. Además, es lento. Tarda más de 35 minutos para que Detox se construya en CI para mí actualmente. Si tienes un enfoque más rápido, genial, eso es realmente genial. Puede tender a ser lento. También, otra razón por la que puede ser lento es si hay un problema de infraestructura, bueno, esto multiplica el impacto de la lentitud. Si hay un problema de infraestructura o un fallo en la prueba, pasará un tiempo antes de que te enteres. Es posible que debas esperar 35 minutos o más para que suceda. Y porque es lento, es caro si pagas por hora. Mis cosas son de código abierto, por lo que es gratis para mí. Muchas gracias, GitHub. Pero si estás pagando por hora, eso puede consumirlo rápidamente. Como resultado, es posible que pruebes menos en CI que en la web. Tal vez no ejecutes toda tu suite de CI. Tal vez no ejecutes toda tu suite de extremo a extremo. Solo ejecutas algunas de las pruebas, pero entonces tienes algunas pruebas que no se están ejecutando, y no estás obteniendo el seguro allí. Entonces eso te dará menos confianza porque se está ejecutando menos de tu suite. Además, finalmente, más y más problemas con el desarrollo móvil y CI. Si tienes una suite que pasa en las máquinas de los desarrolladores, es difícil hacer que todo pase en CI a la vez. Pueden surgir varias causas de flake y problemas. Y por eso, ya sabes, digamos que has comenzado y has conseguido que una suite funcione localmente, y ahora te estás preparando para ejecutarla en CI, te recomendaría habilitar solo una prueba a la vez. No necesariamente ejecutes toda tu suite de extremo a extremo en CI. Consigue que pase una, y de esa manera, cuando pasa, tienes progreso, y puedes pausar en cualquier momento. has progresado en una suite de CI más completa y puedes retomarlo más tarde. Entonces, con eso, quería compartir contigo mi configuración de Detox CI en GitHub Actions. Entonces, quería compartir, solo quiero que esto funcione para saber que tenía una opción para informar a las personas para que no pueda simplemente decir, quiero decir, si estoy enseñando Detox, dejaría que las personas sepan como hay una forma de ejecutar esto en CI porque eso no está garantizado en absoluto. Como he estado en los puntos en el pasado donde no he podido ejecutar Detox en ningún servidor de CI que haya probado. Así que quería que funcionara y lo tengo en un repositorio de código abierto para demostrar que funciona.

23. Configurando Detox para CI con GitHub Actions

Short description:

En esta parte, el ponente demuestra cómo configurar Detox para ejecutar en CI utilizando GitHub Actions. Explican la separación de las pruebas de ejecución rápida de las pruebas de Detox para optimizar el tiempo de retroalimentación. El ponente también aborda posibles problemas con la limitación de la tasa de API y captchas en las pruebas y sugiere el uso de enfoques de simulación para superar estos desafíos.

Entonces, vamos al YAML y veamos qué sucede. No es el código. Son cosas de construcción. Por lo tanto, es una configuración de YAML en su lugar. Esa es mi broma tonta. Entonces. Y algo que quería hacer. Así que aquí hay otro proyecto que configuré. Como una confesión, hablando de complejidad, hacer que Detox funcione en CI. En realidad, no tengo Detox funcionando para Shirley en CI. Solo lo ejecuto localmente. No he podido hacer que Detox testing con Expo se ejecute en CI, al menos para ese proyecto. Así que es un desafío. Pero tengo la caja de arena de pruebas RNCLI testing. Así que déjame mostrarte esto. Quiero decir, te mostraré esta aplicación. Es extremadamente trivial. Ahora, déjame detener este servidor y luego iniciaré este servidor. Para abrir esto, esta es una aplicación cli de react native vamos a intentar abrirlo es muy parecido a una aplicación de hola mundo solo quería hacer que algo funcionara con detox parece que va a hacer una construcción vamos a ver vamos a subir el resto de nuestro tiempo déjame empezar empezaré a hablar por delante um así que mientras esto se está iniciando en realidad voy a comenzar esto corriendo en ci también para que podamos verlo ir mientras avanzamos ahora he cerrado la pestaña así que déjame abrirlo de nuevo escribiendo mal cli testing sandbox así que aquí está el proyecto esto también está vinculado desde el oh está vinculado desde la página correcta podría haber llegado a él desde aquí enlace desde la página está aquí si vas debajo de las acciones puedes ver las carreras de prueba y tengo una prueba y una carrera de detox y ves que que uno de ellos tuvo éxito hace solo tres horas. Y tardó 45 minutos en completarse. No nos quedan 45 minutos en la masterclass, pero de todos modos lo voy a empezar. Entonces sí, esto no, déjame cerrar esto y empezar esto de nuevo. Pero lo que voy a hacer es poner esto en marcha. Git commit, allow empty y rerun CI. Esta es solo una forma de iniciar operaciones de CI dependiendo de cómo tengas configurado Git y PowerPoint. Así que voy a subir eso al servidor. Y vemos en la pestaña de acciones aquí que ha iniciado estos dos procesos diferentes, el de detox y el de prueba. Así que volveremos a revisar eso antes del final de la masterclass. ¿Cómo ha empezado esta aplicación? Esto no parece estar empezando. Oh, está funcionando en mi teléfono porque mi teléfono está enchufado. Oh, Dios mío. Bueno, veamos si puedo iniciarlo individualmente porque uso esa antigua cámara de continuidad. Mi teléfono está justo ahí. Me estás mirando a través de él. Así que intentaré iniciarlo de esta manera. RNCLI testing sandbox. Esa no parece ser la versión correcta del código. Oh, ¿sabes qué? Detox lo iniciará. Eso es correcto. Genial. Así que uso debug para React Native CLI para ejecutar las pruebas al menos localmente. Sí, eso funciona. Así que la aplicación va a empezar. Y observa que eso es literalmente un hola React native, y la prueba confirma que dice Hola. Este repositorio no es sobre los detalles de la prueba, es solo sobre déjame conseguir una prueba de detox funcionando en CI, porque eso es lo difícil que puede ser. Así que veamos la configuración y veamos cómo lo hacemos. Primero tenemos que abrir el repositorio correcto, eso es lo primero que necesitamos hacer. Entonces, primero notarás si has usado GitHub actions antes que debajo de .github workflows es donde van. Y tengo dos separados. Uno es test que podría haber nombrado más específicamente, pero revisaré brevemente esto, esto se ejecuta en Ubuntu y ejecuta ESLint y ejecuta la prueba Jest incluyendo React Native testing library. Así que eso se ejecuta allí y lo separo de detox porque detox tarda mucho en ejecutarse. La prueba se termina en 55 segundos. Detox tarda 45 minutos. Así que quería una forma de obtener retroalimentación más rápida, y lo recomendaría mucho. Así que puedes poner todas tus pruebas de ejecución rápida en una acción que se ejecuta en el hardware Linux más barato, y luego obtienes retroalimentación rápida allí. Entonces, si estas cosas salen mal, te enterarás en 45 segundos. Y tienes que esperar todos los 45 minutos para que se ejecute detox. Por eso lo separé. Así que ahora vamos a repasar esto. Entonces, para mi flujo de trabajo de Detox, así es como configuramos en Github actions cómo ejecutarlo. Oh y solo para hablar sobre el nivel de imagen grande, los detalles específicos de la configuración de CI en Bitrise o algo así van a ser diferentes pero probablemente tendrás todos los mismos componentes en su lugar. Y así estoy demostrando aquí conceptualmente qué tipo de cosas necesitas configurar para hacer funcionar Detox. Y puedes investigar los detalles en tu propia plataforma. Y desafortunadamente necesitarás profundizar en los desafíos de mensajería de error específicos que te encuentres también. Así que puedo configurar esto para ejecutarse en un push a la rama principal. Así que main es mi rama principal. Así que cada vez que hay un nuevo commit en esa rama, que suele ser de una solicitud de extracción que se fusiona hacia abajo, CI debería ejecutarse en ese commit. También lo ejecuto en las solicitudes de extracción. Así que he evolucionado esta lista a lo largo de varios proyectos diferentes, pero lo ejecutamos cuando se abre una solicitud de extracción. Cuando se vuelve a abrir, si lo cierras y lo vuelves a abrir por alguna razón, se volvería a ejecutar. Y también cuando se sincroniza, que creo que solo significa que se ha subido un nuevo commit a la rama en la que está la solicitud de extracción. No lo ejecuto en todas las ramas porque a veces solo subo ramas temporales para trabajos en progreso. Y porque la prueba de detox tarda tanto, es gratis para mí aquí, pero no quiero perder ese tiempo. Y tal vez estoy en progreso en algo y no quiero recibir un error de que algo ha fallado. Y eso es lo que he usado para mis proyectos comerciales también. Tenemos números limitados para mis cosas de clientes donde me siento, sí, solo ejecuta en la rama principal y en las solicitudes de extracción. Acabo de notar una pregunta de James. ¿Tienes problemas con tus pruebas fallando debido a la limitación de la tasa de API o quizás CAPTCHA? ¿Cómo te enfrentas a estos problemas? Sí, entonces hay dos cosas diferentes sobre eso. En cuanto a la limitación de la tasa de API, si utilizas un enfoque de simulación, uno de los muchos enfoques de simulación que enumeré en el diagrama para simular solicitudes a backends reales, eso debería encargarse de la limitación de la tasa de API porque lo has simulado. No estás golpeando una API. Estás golpeando, estás simulado localmente en memoria el array de JavaScript. Y los arrays de JavaScript no tienen límites de tasa de API. Ahora, para aplicaciones realmente complejas, es posible que tengas una serie de diferentes API a las que estás golpeando. Y así como si estás registrando análisis, si estás capturando errores. Y así esos podrían ser casos

24. Configuración de Detox y Ejecución de Pruebas

Short description:

En la empresa de comida rápida, simulamos el inicio de sesión creando una nueva cuenta de usuario o realizando el proceso como invitado. La simulación de captchas se puede hacer añadiendo lógica para desactivar CAPTCHA en modo de prueba. En la configuración de detox, especificamos versiones exactas para Ubuntu y macOS para evitar fallos futuros. Configuramos Node y almacenamos en caché las dependencias de Yarn para descargas más rápidas. También se almacenan en caché las dependencias de CocoaPods. El CLI de Detox y las dependencias se instalan globalmente. Construir la aplicación para Detox lleva tiempo, especialmente para aplicaciones nativas de iOS o Android. React Native Testing Library proporciona una retroalimentación más rápida que Detox, pero Detox ofrece realismo en las pruebas móviles. Se deben configurar las acciones de GitHub para que se ejecuten en ramas específicas. Detox funciona en macOS 12, pero se agota el tiempo en macOS 13.

Esto también ocurrió en la empresa de comida rápida. Creo que olvidé cómo simulamos el inicio de sesión. Es posible que hayamos creado una nueva cuenta de usuario cada vez o simplemente hayamos realizado el proceso como invitado. Así que sí, estoy simulando captchas. No estoy totalmente seguro. pero existe la opción de añadir lógica a tu código donde si estás en modo testing, simplemente desactivas algo como un CAPTCHA por completo. Eso es menos realismo, pero puede evitar tener que golpear un servicio externo y tener que escribir una prueba que demuestre que es humano, lo cual puede ser difícil de hacer. Espero que eso sea útil.

Bien, volvamos a la configuración de detox. Así que estamos ejecutando en la rama principal y en las solicitudes de extracción. Luego configuramos la aplicación. He encontrado, te darás cuenta en ambas pruebas, que especifico una versión exacta, Ubuntu 22.04 y Mac OS 12. He encontrado que cuando he dicho simplemente Mac OS más reciente, Ubuntu más reciente, mis pruebas fallarán aleatoriamente en el futuro porque algún paquete del sistema operativo ha sido actualizado y alguna dependencia necesaria ya no está allí. Generalmente encuentro que bloquear a una versión específica es útil para evitar fallos que no están relacionados con mi aplicación. Verifico el código. Configuro Node localmente. 18 es lo que se recomienda para Expo, así que lo configuro. Esta acción almacena en caché las dependencias de Yarn y de esa manera después de la primera ejecución o después de cada vez que se actualiza el archivo Yarn, los archivos Log, se almacenan en caché para acelerar las descargas futuras. Necesitamos cada bit de aceleración que podamos obtener. Aquí hay un comando personalizado para almacenar en caché las dependencias de CocoaPods, porque estamos haciendo una construcción nativa real del- bueno esto es RNCLI, así que necesitamos esas dependencias de CocoaPods. Y no está integrado pero esta es solo una configuración de una acción de caché que encontré que alguien recomendó en línea que parece que ha funcionado. para trabajar. Necesitas instalar las dependencias de npm y las dependencias de iOS. Un yarn instala y archivo de bloqueo congelado, es probable que ya hagas esto en CI, pero si no lo has hecho, eso simplemente asegura en algunas circunstancias que no puedo recordar cuándo, yarn instalará realmente cambiará el archivo de bloqueo. Olvidé cuándo, pero esto asegura que eso no es posible porque si el archivo de bloqueo está cambiando, quieres que eso se confirme. Quieres que CI diga, oye, hay algo que necesita cambiar en el archivo de bloqueo, puedes cambiarlo localmente, confirmarlo. De esa manera no tienes desarrolladores ejecutando diferentes versiones del código localmente. Así que también instalamos esas dependencias de CocoaPod. Luego necesitamos instalar el CLI de detox globalmente. Si has configurado detox localmente, sabes que tienes el CLI de detox ejecutándose para obtener ese comando detox. Así que necesitamos configurarlo así como las las dependencias por cierto. Así que lo que tengo ejecutándose aquí en CI es solo iOS. Curiosamente, Android tiende a ser más difícil de configurar en CI para pruebas de extremo a extremo testing que iOS. Incluso los desarrolladores de Android de Big Nerd Ranch validan eso. Creo que la razón es porque, porque Apple es todo en uno, tienes que ejecutar en una Mac para ejecutar iOS de todos modos. Y por lo tanto, tienen la mayoría de las cosas que se necesitan incorporadas en Android como código abierto. Hay tantas piezas. ¿Y este distro de Linux tiene las cosas que se necesitan? Así que puede ser cambiado. desafiante. Así que no he conseguido que funcione, y no he priorizado. Soy una persona de iOS. No he priorizado Android en mis proyectos paralelos. Pero estoy seguro de que un enfoque de Android sería algo como esto con soluciones para problemas ambientales y dependencias y algo así. A continuación, construyo la aplicación para Detox. Y luego aquí hay una acción útil que alguien ha configurado. Gracias, FutureWare Tech, que inicia un simulador. Todo lo que tienes que hacer es pasar el nombre del modelo. Necesita ser uno que esté configurado en esa versión de macOS. lo arrancará para ti y luego puedo simplemente ejecutar detox test y ejecuto la suite de pruebas completa en este caso bueno solo hay una prueba en este caso y eso se ejecuta así que esos son los pasos que están configurados allí vamos a ver cómo va así que tenemos nuestra suite de pruebas que ejecuta la prueba jest completada en 46 segundos muy bien detox está en ocho minutos y eso no está ni cerca de terminar en absoluto como eso es solo empezando. Así que veamos cómo se ve. Así que tenemos vamos a estar desplazándonos aquí. Déjame intentar acercar el texto para ti. Así que nuestra prueba aquí, mira eso, configura node. Almacenó en caché el las dependencias de CocoaPods e instaló estas dependencias. Y ahora estamos construyendo la aplicación para Detox. Ahora estamos en la línea 12,682 de la salida. Así que eso es agradable y bueno. Parece que está en realidad se ha desplazado hasta el fondo. Pero al final de la ejecución de la prueba, puedes obtener la salida completa porque está construyendo la aplicación completa para hacer una prueba de extremo a extremo. Necesitas que React Native construya tu aplicación nativa de iOS o Android. Y por lo tanto, está pasando por todo eso. Y porque esto no es, quiero decir, no lo sé. Tal vez si pagas por GitHub actions, obtienes un procesador M2 más reciente. Pero imagino que eso no es lo que me están dando gratis. Y así, incluso una construcción que solo me lleva un par de minutos localmente. Hombre, está corriendo tanto tiempo aquí. Tarda 45 minutos en el hardware gratuito que proporcionan. Y así está dando toda la salida. Estamos compilando C. Estamos construyendo toda la aplicación desde cero, esa pila fija, y esto nos lleva de vuelta a la pila. Las pruebas de React Native Testing Library, solo ejecutan JavaScript. Tienes tu código JavaScript, vamos a ejecutarlo. Detox necesita una aplicación en ejecución y construida, y por eso tenemos que construir todo el C, todos los RCT fallis, y todas las otras dependencias de CocoaPods que son necesarias para poner en marcha nuestra aplicación, y eso lleva un tiempo. Diferencia de velocidad. Por eso, incluso más en móviles nativos que en web, no recomendaría escribir todas tus pruebas en Detox. Puedes obtener una retroalimentación mucho más rápida. Quiero decir, no podría ser una ilustración más clara que esta. Obtienes una retroalimentación mucho más rápida de React Native Testing Library que de Detox. Eso no significa que Detox sea malo, pero significa que incluyas React Native Testing Library en la mezcla. te lo agradecerás a ti mismo. Tu yo futuro te lo agradecerá, pero también ejecuta Detox para obtener el realismo de esa retroalimentación. Realmente es ambas cosas en el mundo de las pruebas móviles. Bien, veamos qué me he perdido en mis notas sobre esto. Sí, eso está corriendo. No está completo, pero vamos a las diapositivas y revisamos de nuevo lo que vimos solo para verlo en un resumen un poco. Así que en GitHub Actions, configuras en qué ramas se va a ejecutar, y recomendaría no ejecutar en cada una de las ramas y en cada uno de los commits. Vas a agotar tus minutos. Ejecútalo solo en la rama principal y en las solicitudes de extracción abiertas es lo que recomendaría hasta que encuentres que necesitas algo diferente. Ejecuto Detox en macOS 12. Para mí actualmente y durante seis meses o más ahora, se agota el tiempo en macOS 13.

25. Flujo de Trabajo de Desarrollo Local con Detox

Short description:

Para incorporar Detox en tu flujo de trabajo de desarrollo local, comienza probando las características existentes. Enfócate en las características que ya funcionan bien y que han sido probadas manualmente. Añade pruebas a estas características, omitiendo cualquier cosa que sea desafiante para probar, como los CAPTCHAs. Si la prueba es difícil para una característica, intenta probar una diferente.

Aún no he probado Sonoma. No he instalado Sonoma en este portátil porque he estado esperando hasta después de esta masterclass. No quería estropear las cosas. Esa es otra parte de la fragilidad del ecosistema de React Native. Me encanta React Native. Si actualizas Xcode como si tuvieras un problema, vas a tener que solucionarlo o actualizar react native a una nueva versión, así que de todos modos aún no estoy ejecutando Sonoma, pero mañana al final de esta semana voy a instalarlo, revisarlo, configurar node porque vas a necesitar node localmente eso se encargará de la caché de las dependencias ya, pero probablemente querrás almacenar en caché esas dependencias de CocoaPods, ahorra todo el tiempo que puedas, vas a instalar tus dependencias de JavaScript y nativas y vas a poner en marcha esas cosas del CLI de Detox. Oh, una nota más sobre esto, déjame volver al archivo completo. Um, ¿cómo decidí en qué orden poner estos pasos? Conceptualmente, es algo así como, bueno, ya sabes, CLI de Detox, esta es la configuración del entorno. ¿No lo pondrías arriba con node antes de instalar tu aplicación local? Lo que encontré es, desafortunadamente porque CI con móvil nativo es difícil. Hago un montón de solución de problemas. Hay un montón de intentos de arreglar esto, intentos de arreglar aquello, todos estos commits, enviándolos a CI para ver si funcionan o no. Así que hay un montón de prueba y error. Y con esos, cualquier paso que esté fallando para mí, lo pongo lo más alto en la lista que puedo. Como yo. Ya sabes, si si la caché de las dependencias de pausa está dando error, no quiero poner eso al final. No sé si eso tiene sentido. De todos modos, el punto es, como si instalar DDoS CLI no estuviera funcionando bien. Lo pondría temporalmente justo al principio lo más alto que pudiera para obtener una retroalimentación más rápida. Y luego, oh, creo que un ejemplo fue intentar actualizar la versión del simulador de iPhone de FutureWare. Construir la aplicación Detox es lo que más tiempo llevó. Y así estaba tratando de averiguar qué versiones del iPhone estaban disponibles en el simulador. Subí esto hasta el tope. Lo puse allí para poder visualizarlo. Quizás justo después del checkout porque iniciar un simulador no necesita que se ejecute ninguno de mis códigos. Y así podría obtener la retroalimentación rápida allí y luego lo puse cerca del final. Porque una vez que el proceso de construcción está funcionando, es tu código el que va a cambiar con más frecuencia. Y así lo pones más alto. Así obtienes la retroalimentación sobre eso lo más pronto posible. Así que realmente no hay una fuerte dependencia en el orden en que estos pasos están. Así que sí, definitivamente siéntete libre de mover las cosas mientras estás solucionando problemas. Date la retroalimentación más rápida que puedas mientras estás solucionando problemas. Así que instalamos estas dependencias. Construimos la aplicación. Lanzamos el simulador y luego ejecutamos las pruebas de Detox. Y déjame mostrarte la salida de una ejecución exitosa pasada para que podamos verla. Y espero mantener este repositorio funcionando indefinidamente. Lo actualicé a versiones más nuevas hace unas semanas, pero es como, solo quiero seguir demostrando a mí mismo que puedo, de hecho, ejecutar Detox en CI. Así que, esta es una ejecución exitosa anterior. Y cuando miras allí, puedes ver la salida. y bajo el, bueno, la construcción va a mostrar muchos pasos. Observa que son 36 minutos. Y luego la ejecución de detox tomó tres minutos. Así que podemos abrir eso. Vemos la salida. Esto es en realidad la salida similar a la que ves localmente. Sí, interesante. Sí, es interesante que tardó un par de minutos en iniciarse. Supongo que eso es solo porque se está ejecutando en un hardware de CI de baja potencia. Pero vemos la misma salida que verías localmente de detox, y dirá si pasó o si falló. Sí. Así que sí. Así que volviendo atrás, esa es mi configuración de detox. Eso es todo específico de las acciones de GitHub, pero ¿cuáles son nuestras conclusiones en general si estás en una diferente plataforma? Así que lo que diría es que estás intentando configurar detox en CI, elige una potencial CI plataforma. Tal vez tengas una porque tu organización ya tiene una cuenta, o es lo que conoces, o suena como si desde la blogosfera se recomendara tener buen soporte para React Native. Y luego antes de hacer cualquier otra cosa, intenta pasar una prueba de arranque. No lo sobreingenierices. Y ciertamente no, ya sabes, obtén esa retroalimentación rápida. Como, podría no funcionar. Lo siento. Sería el portador de malas noticias. Así que intenta pasar una prueba de arranque. Incluso podrías, tal vez ni siquiera tu aplicación, tal vez incluso conseguir que RNCLITestingSandbox o tu propia aplicación independiente de React Native o Expo, si estás usando Expo, intenta pasar una prueba de arranque pasando. Porque si no puedes hacer que eso funcione, no vale la pena poner el tiempo para escribir un extenso conjunto de pruebas para el tuyo o intentar hacer que tu aplicación funcione. Y si no funciona, prueba otra plataforma. Puede que tengas que seguir golpeándote la cabeza alrededor de ella, pero puedes encontrar que algo más funciona mejor. Tal vez tu organización tiene una cuenta de GitHub o de GitLab pero tal vez encuentres que BidRise es una plataforma de la que oigo muchas cosas buenas para móviles, aunque no la he probado yo mismo. Y así tal vez encuentres que Bitrise simplemente funciona mejor, especialmente para Android. Puedes encontrar que una plataforma específica para móviles para CI simplemente funciona mejor. Puedes ser capaz de hacer un caso a tu organización como, oye, no estamos tratando de ir fuera del camino trillado. Todo lo que estamos tratando de hacer es que el móvil tiene algunas necesidades específicas. Y si tu organización hace mucho desarrollo web, hay diferencias para móviles. Probablemente ya lo sepas ya. Y así puedes ser capaz de hacer un caso para usar Bitrise o algo que funcione mejor para tu caso móvil específico. Pero mi punto aquí es simplemente decir, no pongas un montón de esfuerzo en una plataforma CI específica antes de averiguar si puedes hacerla funcionar, porque es simplemente eso difícil. Desearía tener una solución lista para usar para todos los casos. Tal vez si consigo un trabajo como un tester a tiempo completo de React Native, puedo hacer eso en el futuro, pero ahora mismo no está en las cartas. Así que eso es CI para React Native. No vamos a tomar un descanso porque nos quedan 10 minutos. Voy a buscar preguntas, no busco preguntas, um voy a repasar brevemente esta última sección fue corta de todos modos y así creo que vamos a tener tiempo para ello um solo para repasar brevemente habla a través de ella flujo de trabajo de desarrollo local con detox así que te dejaré con estas últimas recomendaciones así que digamos que has llegado a este punto donde tienes detox configurado tienes tu backend simulado um tienes algunas pruebas iniciales en su lugar um y las tienes corriendo en CI genial esas son son nuestras pruebas iniciales. ¿A dónde vamos desde aquí? ¿Cómo incorporamos detox en nuestro flujo de trabajo de desarrollo local? Así que aquí están las tres etapas que recomendaría. Aquí hay una forma de pensar en ello para empezar a ganar impulso en las pruebas de detox. Número uno, prueba las características existentes. Así que ya tienes características en tu aplicación que ya están funcionando. Usas la aplicación y las has probado manualmente y tus usuarios no se están quejando. Así que esas características están funcionando. Así que eso es la mitad del trabajo hecho. Puedes tomar esas características y añadirles pruebas. Y yo diría, ya sabes, porque algunas cosas pueden ser más desafiantes para probar que otras, como se mencionó anteriormente sobre los CAPTCHAs, tal vez algo como un CAPTCHA es difícil de probar. Omite eso, prueba algo más en su lugar. Si las pruebas son difíciles para una característica, prueba una diferente.

26. Pruebas Efectivas con Detox

Short description:

Para garantizar una mejor cobertura de pruebas, comienza probando las características existentes y compromete las pruebas que funcionan en tu rama principal. A medida que agregas nuevas características, pruébalas para mantener el ritmo de cobertura. Considera el desarrollo guiado por pruebas para una cobertura de pruebas exhaustiva, código fácil de probar y código mínimo. El desarrollo guiado por pruebas te permite escribir código basado en las pruebas y refactorizarlo en el futuro a medida que cambian los requisitos. En resumen, discutimos las pruebas con Detox, la falsificación de la capa API, la determinación de la cobertura de pruebas, Detox en CI y las etapas del desarrollo de Detox.

De esta manera, al menos estás obteniendo alguna cobertura de pruebas. Algo es mejor que nada. Ahora, a medida que avanzas, puedes notar que es posible que debas hacer cambios. Como quizás necesites poner IDs de prueba en su lugar. Detox recomienda usar IDs de prueba para testing. También puedes buscar cosas a través del texto. Hay compensaciones allí, ve lo que funciona para ti, pero es posible que debas poner IDs de prueba. Como ese ejemplo que mostré donde el texto en un botón cambiaba dependiendo del día de la semana, pero un ID de prueba lo hizo más estable. Cada vez que consigues que una prueba para una característica existente funcione, comprométela, ponla en tu rama principal porque nunca sabes cuándo te vas a encontrar con un obstáculo. No dejaría pruebas funcionales en una rama en algún lugar, ponlas en su lugar para que sean beneficiosas. Y de esa manera, las personas podrán mantenerlas funcionando a medida que ocurren cambios en tu aplicación. Y al final, al menos tendrás algunas de tus características cubiertas por pruebas, y tendrás algunos conjuntos de ejemplos de pruebas a los que referirte en el futuro. Cada ejemplo adicional de prueba de detox que tengas es un ejemplo más al que puedes referirte en el futuro, lo cual es genial.

Paso dos, que diría que vayas aquí, pero no necesariamente necesitas que todas tus características existentes estén cubiertas por pruebas. Pero etapa dos, una vez que tienes algunas características existentes cubiertas por pruebas, puedes probar características a medida que las agregas. Cuando estás agregando una nueva característica, es cuando los requisitos y el código están más frescos en tu mente. Y así, si te encuentras con desafíos al agregar una prueba para ello, tendrás la mayor cantidad de información para poder hacer ajustes y modificaciones rápidamente. Y es más fácil hacer cambios según sea necesario para apoyar el testing. Sabes, consigue que una característica funcione y luego pon en su lugar una prueba de extremo a extremo de Detox para ello. Entonces ahora, incluso si no tienes una cobertura total de pruebas de detox, estás manteniendo el ritmo con las características o aumentando lentamente tu porcentaje de cobertura de pruebas con el tiempo porque las nuevas características que estás agregando pueden ser cubiertas. Y tal vez algo es una integración de hardware esotérica y extraña o una integración de terceros, y descubres que es difícil de probar. Pero si aún puedes probar la mayoría de tus características a medida que las agregas, estás obteniendo una buena cobertura de pruebas.

La etapa número tres que puedes considerar es el desarrollo guiado por pruebas. El desarrollo guiado por pruebas es definitivamente controvertido en los últimos años. Y no estoy diciendo que tengas que hacerlo. No te estoy criticando como desarrollador y probador si no haces desarrollo guiado por pruebas. Especialmente en móviles, especialmente en Detox, no sé si hay alguien más allí hablando sobre desarrollo guiado por pruebas aparte de mí. Y por lo tanto, podría no ser útil en tu aplicación. Pero lo que estoy diciendo es, si llegas al punto donde te sientes cómodo testing características a medida que las agregas, podrías considerar el desarrollo guiado por pruebas. Te señalaré una charla que di en React Native EU el año pasado. Se llama Mejorando Todo el Tiempo, Cómo Escapar del Mal Código. En esta charla, hago el caso de por qué podrías querer considerar el desarrollo guiado por pruebas y cómo puede ayudar. En esta charla, creo que demuestro el nivel de componente TDD usando React Native Testing Library. Pero hace un caso de por qué podrías querer considerar el desarrollo guiado por pruebas. No vamos a tener tiempo para ir al código, pero tengo otro sitio web de tutoriales. uh está vinculado está en las diapositivas y está vinculado desde aquí para aprender TDD en React Native y así este te guiará a través de un flujo de trabajo que en realidad es un enfoque que se llama desarrollo guiado por pruebas de afuera hacia adentro donde primero escribes una prueba de detox para tu característica pasando por todo el flujo como hemos visto antes y luego ejecutas esa prueba y luego para cada fallo que obtienes bajas al nivel de código y escribes solo el código suficiente para superar ese fallo um y así terminas escribiendo pruebas TDD de nivel inferior a nivel de componente en React Native Testing Library para que funcionen, y luego vuelves al nivel de detox. Así que es una forma realmente natural y genial de averiguar cuánto detox y cuánto RNTL debería escribir localmente, y puede guiarte a través de las cosas. Permíteme hablar sobre, así que no vamos a entrar en el ejemplo. Puedes revisar esto por tu cuenta si quieres, y siempre puedes contactarme más tarde con preguntas, pero permíteme dar algunas razones por las que podrías querer considerar el desarrollo guiado por pruebas. E incluso si encuentras que el flujo de detox no es útil, aún podrías hacer desarrollo guiado por pruebas para componentes individuales. TDD resulta en una cobertura de pruebas exhaustiva. No voy a decir 100% de cobertura de pruebas porque puede haber algunas cosas de cableado y cosas nativas que no valen la pena escribir JavaScript TDD para, pero obtienes una cobertura de pruebas realmente exhaustiva porque no escribes código d

27. Comentarios Finales y Pruebas en Múltiples Dispositivos

Short description:

Puedes contactarme a esta dirección de correo electrónico u otras formas que están en la página principal de la masterclass. Muchas gracias a los organizadores y a los asistentes. Buena suerte con las pruebas de detox, es una gran herramienta. React Native es una gran herramienta. Por favor, ponte en contacto si puedo ayudarte en el futuro. Veo una pregunta de James sobre las pruebas con múltiples dispositivos y versiones de OS. Las pruebas en múltiples configuraciones pueden ser importantes, especialmente para aplicaciones profesionales. Ejecutar en dispositivos físicos reales puede aumentar la confianza. Sin embargo, puede haber desafíos con los dispositivos de hardware que no controlas, como las actualizaciones de OS. Los profesionales de la automatización de pruebas a menudo utilizan servicios como Appium con Sauce Labs para ejecutar en dispositivos reales y gestionar la inestabilidad. Gracias de nuevo a todos por asistir.

Así que con eso, voy a terminarlo un minuto antes del tiempo final. Muchas gracias a todos por unirse. Lo aprecio. Aprecio las preguntas. Por favor, no dudes en contactarme en el futuro. Puedes contactarme a esta dirección de correo electrónico u otras formas que están en la página principal de la masterclass. Me encantaría saber de ti. Siempre me encanta hablar sobre testing y generar ideas sobre esto. Y ciertamente si la consultoría en la que estoy, Test Double puede ayudarte, nos encantaría saber de ti también.

Muchas gracias de nuevo a los organizadores y a los asistentes. Estaré aquí por unos minutos para responder preguntas en el chat de Zoom, pero realmente lo aprecio. Buena suerte con las pruebas de detox, es una gran herramienta. React Native es una gran herramienta. Y así espero que con estos principios pragmáticos puedas navegar por la selva de las pruebas de react native para encontrar un enfoque que funcione para ti. Por favor, ponte en contacto si puedo ayudarte en el futuro. Muchas gracias. Y ahora voy a mirar las preguntas de Zoom.

Y si seguimos con la grabación, veo una pregunta de James que dice, he notado en el desarrollo móvil, que a menudo prueban con múltiples teléfonos diferentes y diferentes versiones de iOS. Basándote en tu archivo YAML, sólo pusiste iPhone 14, pero no especificaste la versión del OS. ¿O importa o es caso por caso? Esa es una gran pregunta, James. Y esa es una pregunta tan buena que si hago esta masterclass de nuevo, voy a poner una respuesta a esa pregunta allí. Así que para mi RN-CLI testing sandbox, sólo quería hacer funcionar una prueba, y así que sólo probé una configuración. Para mi proyecto paralelo Shirley, es sólo un proyecto paralelo, y no gano dinero con él, así que no encontré mucho. Simplemente no me motivó probar diferentes OSs o diferentes dispositivos. Pero para el desarrollo profesional, a menudo he encontrado que las diferentes versiones de OS y los diferentes dispositivos son importantes, Pero ciertamente cuando tienes diferencias en tu aplicación y el diseño, dependiendo del factor de forma de la pantalla, eso puede ser importante para probar también. Una de las cosas buenas de Appium en realidad es que está bien configurado para integrarse con servicios. Creo que Sauce Labs es el nombre de uno de ellos que en realidad ejecutará en granjas de dispositivos físicos reales. Así que no sólo estás simulando un Samsung Galaxy 7 o lo que sea, estás ejecutando en un verdadero Samsung Galaxy 7. Así que puedes elegir los dispositivos Android más comunes e importantes, especialmente importante para Android, pero el ecosystem de Apple es muy diverso también. Y puedes elegir dispositivos reales y ejecutar en ellos y eso puede realmente aumentar tu confianza. Y puede que necesites ejecutar diferentes pruebas que digan, okay, estamos en tablet aquí. Así que necesitamos hacer las cosas de manera diferente porque el flujo de usuario es diferente en tablet. Así que eso puede aumentar tu confianza. Pero definitivamente he encontrado cuando se ejecuta en estos dispositivos de hardware que no controlas, como quién sabe cuándo va a aparecer una actualización de OS. Por eso los profesionales de la automation de pruebas que ejecutan en Appium con Sauce Labs, no lo conectan a la integración continua. No fallan en la construcción y previenen despliegues cuando esos fallan. Ven, okay, esos profesionales de la automation de pruebas miran los fallos. Okay, sí, hemos estado siguiendo la fiabilidad de este a lo largo del tiempo. Sí, ese Samsung Galaxy 7 en Sauce Labs es un poco inestable. Como que probablemente deberíamos sacarlo de la mezcla de pruebas. Probablemente deberíamos dar feedback a Sauce Labs y ver si pueden arreglarlo. Así que hay más imprecisión allí. Hay más inestabilidad que puede ser un desafío. pero para aplicaciones profesionales, y ciertamente cuanto más puede variar tu aplicación dependiendo del hardware, tal vez un dispositivo tiene una integración de hardware, otro no la tiene, diferentes tipos de biometría, así que quieres probar esos caminos. Así que para esas aplicaciones profesionales de alto perfil, las pruebas en múltiples configuraciones pueden ser importantes. Simplemente no tengo eso configurado en mi ejemplo. Gracias por esa pregunta, James. Bueno, muchas gracias a todos. Lo aprecio. Puedes contactarme por correo electrónico u otros mecanismos en la página web allí, pero de nuevo, Muchas gracias a los organizadores, gracias a las personas que asistieron, y a las personas que están viendo esta grabación más tarde. Por favor, avísame si puedo ayudar. Muchas gracias a todos. Que tengan un buen día.

Watch more workshops on topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
WorkshopFree
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.