Cocina de Pruebas: Una Receta para Buenos Tests

Mi nombre es Iris, que en griego significa arco iris. Soy una ingeniera de software de Austria, pero he vivido en diferentes lugares de Europa y actualmente considero a Londres mi hogar. Y la razón por la que elegí un título relacionado con la cocina para mi charla es que no he hecho mucho más desde que comenzó la pandemia. Desde pasta casera, pan y pizza, hasta noches temáticas como África Occidental, Sri Lanka, México o mi propio Vamana, prácticamente he hecho de todo en el último año. Así que si tienes alguna receta interesante o algo de tu país de origen que te gustaría compartir

conmigo, por favor envíamelas en Twitter, mi mano está justo ahí arriba. Y cuando no cocino, desarrollo productos para nuestros usuarios en Spotify. En caso de que no estés familiarizado con Spotify, somos uno de los servicios de transmisión de audio más grandes del mundo con más de 70 millones de canciones, incluyendo 2.2 millones de títulos de podcasts. Y con casi 350 millones de usuarios activos mensuales, puedes imaginar que la calidad y las prácticas de pruebas se toman muy en serio aquí. Así que vamos a sumergirnos en las directrices. ¿Recuerdas la diapositiva? ¿De dónde saqué todos los adjetivos? La verdad es que no he pasado casi suficiente tiempo en este espacio para crear una lista completa de propiedades que debería tener una prueba. Así que prefiero dejar eso a alguien que sí lo ha hecho, como Kent Beck. En un artículo de Medium en 2019, Kent enumera 12 propiedades de este tipo. Pero ¿qué significan en detalle? Veámoslas una por una y veamos cómo podemos usarlas para escribir mejores pruebas y código en JavaScript y React. Empecemos con lo que creo que es el más importante de todos ellos y probablemente el único de la lista en el que nunca, nunca haría concesiones. Las pruebas deben inspirar confianza. Confianza en que tu aplicación funciona. Pensemos en un ejemplo aquí. Quieres refactorizar una parte central de tu aplicación. Tal vez quieras, no sé, pasar de la gestión del estado y Redux al API de contexto. O tal vez quieras usar un script para migrar tu código de JavaScript a typescript. No pensemos en las pruebas automatizadas por un momento, sino en cómo generalmente abordarías un cambio grande como ese. ¿Simplemente cambiarías el código y lo implementarías? Al menos yo sería extremadamente cuidadoso y probaría exhaustivamente cada parte que estoy modificando antes de implementar, porque esa prueba manual es lo que me da la confianza de que no acabo de romper la aplicación. Y eso es exactamente de lo que se trata las pruebas. Inspirar esa confianza y permitirte refactorizar tu aplicación sin el miedo de romperla. Y eso me lleva perfectamente al segundo punto, las pruebas deben ser automatizadas y ejecutarse sin intervención humana. Supongamos que trabajas en un proyecto más grande donde varios equipos están en diferentes componentes de tu aplicación. Ahora quieres cambiar una sola línea en el componente de botón base que todos los demás equipos utilizan. No solo requerirá mucha coordinación de todos estos equipos diferentes, sino que las pruebas también tendrán que ser un esfuerzo conjunto porque es posible que puedas cambiar el botón, pero no sabes cómo se utiliza en todos los lugares diferentes de la aplicación. Y simplemente no es factible que este y cualquier otro cambio aparentemente pequeño tenga que pasar por pruebas manuales en cada implementación porque la coordinación y el esfuerzo de tiempo son demasiado altos y crecen con la escala de la aplicación también. Así que si quieres permitir que los equipos trabajen de forma autónoma e iteren rápidamente en su parte de la aplicación a cierto tamaño, solo puedes lograrlo a través de la automatización. Eso me lleva de vuelta a la pregunta, ¿cuándo deben ejecutarse las pruebas automatizadas? Y la respuesta es básicamente todo el tiempo. Durante el desarrollo, ayuda tener un ciclo de retroalimentación rápida para al menos ejecutar pruebas unitarias en modo de observación para poder encontrar errores temprano antes de siquiera enviar algún código. Una vez que estés listo para fusionar tus cambios, todas tus pruebas deben ejecutarse en esa rama. Luego, después de la fusión, antes de implementar en producción, tus pruebas deben ejecutarse en la rama principal también. Esto incluye pruebas unitarias, pruebas de integración y, si es posible

pruebas de extremo a extremo si tienes una forma de ejecutarlas en esta rama. Por último, en un sistema más grande con muchos servicios y sitios web que interactúan entre sí, es posible que desees ejecutar tus pruebas cada vez que haya cambios en las dependencias aguas arriba. Porque a menudo no sabes exactamente cuándo ocurre eso. Y mi equipo a menudo cambia de escritura a E cada par de horas.

Es posible que ahora te preguntes, ¿no es esto impráctico? ¿No te ralentiza el despliegue con fallos? Aquí es donde entra el siguiente consejo. No quieres tener que esperar media hora para que tus pruebas pasen antes de poder implementar una corrección urgente. O peor aún, desactivar las ejecuciones de prueba en correcciones de errores importantes porque tardan demasiado en ejecutarse. Esto eliminaría la confianza de nuevo de la que hablamos anteriormente y haría que escribir pruebas fuera inútil. Pero ¿cómo podemos hacer que nuestras pruebas sean rápidas? En primer lugar, nada dice que debamos ejecutar las pruebas de forma secuencial. Si hay algo que te ahorrará mucho tiempo al ejecutar tus pruebas, es ejecutarlas en paralelo. Luego no es necesario ejecutar todas tus pruebas con cada cambio. Solo vuelve a ejecutar la prueba relacionada con los archivos que realmente has cambiado o tocado. Puedes hacer esto en muchas herramientas. El modo de observación lo hace, por ejemplo.

Otra cosa que me gusta hacer en mis pruebas de integración es simular dependencias lentas como llamadas de red, animations o cualquier cosa relacionada con temporizadores. Si tienes un componente de cuenta regresiva, que muestra el final de la cuenta regresiva después de dos segundos, no me quedaría esperando dos segundos para que eso suceda hasta que pueda confirmarlo. En su lugar, simularía los temporizadores y ejecutaría todos ellos, y también hay formas de asegurarse de que hayan pasado exactamente dos segundos. Hacer esto hará que mi prueba sea más determinista y más rápida, pero siempre tengo cuidado de no simular demasiado porque quiero probar mis componentes como lo haría un consumidor.

Por último, otro consejo para hacer que tus pruebas sean más rápidas es ejecutarlas en el entorno adecuado. Lo que quiero decir con eso es que no ejecutes pruebas para una función de utilidad en un navegador real, por ejemplo, sino que utilices herramientas como JS DOM, que son más rápidas pero una buena aproximación de un entorno de navegador. Opta por la herramienta más rápida que aún te brinde confianza.

Muy bien, y ahora, ¿cómo escribir pruebas que te den confianza? Las pruebas deben ser comportamentales, estructuradas y sensibles. Habla menos. Lo que esto significa para mí es que debo pensar en la responsabilidad de la cosa que estoy testing. Si estoy testing una función, la llamaría como lo harían sus consumidores. Si es un componente de React utilizado por nuestros usuarios, pensaré en cómo interactúan los usuarios con él e intentaré replicarlo. Si evitas testing desde la perspectiva interna de los componentes y en su lugar encuentras formas de testing desde la perspectiva de tus consumidores, ya sea otro componente de React o un ser humano, probarás el comportamiento del sistema bajo prueba en lugar de la estructura interna. Esto también significa que ahora puedes cambiar la estructura interna como desees o refactorizar el componente sin tener que tocar la prueba. De repente, la prueba realmente se convierte en una forma de asegurarte de que tu comportamiento no ha cambiado mientras trabajabas en el funcionamiento interno. Veamos un ejemplo práctico. Digamos que tenemos un componente de contador que

El contador aumenta cada vez que haces clic en un botón. ¿Cómo lo probarías? Podrías, por ejemplo, verificar el estado interno del botón, del contador, perdón, luego llamar a la propiedad on click del botón y luego verificar que el estado interno del contador ha incrementado. Si haces eso, si solo cambiamos el nombre del estado interno de contador a, digamos, número de clics, la prueba seguirá funcionando ya que el comportamiento sigue siendo el mismo. Entonces, personalmente, lo que haría en su lugar es verificar el texto que se muestra a los usuarios, porque esa es la parte del comportamiento en la que estamos realmente interesados. Entonces, si quieres probar un comportamiento en lugar de una estructura de tu componente, no examines los estados internos para probar la lógica, sino prueba el cambio resultante en la interfaz de usuario como lo haría un usuario. Y hay algo más extraño con esta prueba. Estamos confiando en la propiedad on click del botón principal. Si elegimos cambiar el botón de alguna manera, por ejemplo, si usamos un botón secundario o si cambia el nombre de la propiedad on click, nuevamente nuestra prueba fallará, aunque el comportamiento siga siendo el mismo. En cambio, optaría por simular realmente un clic en incremento, porque eso es lo que un usuario también haría. Por lo tanto, no pruebes el comportamiento de tu componente llamando directamente a las propiedades de los componentes de React. En su lugar, simula el comportamiento real del usuario. Ahora, veamos algunas propiedades más de las buenas pruebas. Las pruebas deben ser deterministas, aisladas y componibles. Pero, ¿qué significan realmente estas palabras en el contexto de nuestras aplicaciones de React para las pruebas? Comencemos con determinista. En el fondo, esto significa que dadas las mismas entradas, tu prueba siempre te dará los mismos resultados. No hay aleatoriedad, no hay fallas intermitentes. Y esto es genial porque si tus pruebas de hecho fallan al azar, no puedes confiar en ellas y no te brindarán esa confianza de la que hablamos. Ahora, aisladas. Esto significa que tus pruebas no dependen entre sí. Y si las pruebas están, de hecho, aisladas, eso hace que sean componibles. Se pueden ejecutar en cualquier orden y siempre producirán el mismo resultado. Las pruebas que tienen estas propiedades tienen dos beneficios principales. Por un lado, si las pruebas están aisladas, también lo están las fallas. Esto facilita mucho encontrar dónde se produce un error. Por otro lado, también hay una ventaja práctica. Si el orden no importa, puedes ejecutarlas en paralelo, lo que probablemente mencioné que es mucho más rápido. En resumen, estas tres propiedades son propiedades de pruebas robustas. Son autosuficientes y no fallan al azar. ¿Cómo podemos lograr eso? Bueno, una excelente manera de hacer que tus pruebas sean más robustas es haciendo que el código subyacente sea más robusto en primer lugar. Veamos cómo podemos hacer ambas cosas. Una cosa que ayudará

React no está cambiando el estado fuera del alcance de tu código. Si realmente tienes que cambiar estados fuera de tu alcance, para hacer pruebas aisladas y eliminar dependencias entre ellas, deberás restablecer los cambios en tu estado global antes y después de cada prueba. Veamos un ejemplo. Aquí, por ejemplo, tenemos un módulo de productos que escribe en un almacenamiento global de productos. Tiene funciones para recuperar, agregar y eliminar productos. La primera prueba aquí tiene una manzana y un plátano, y la segunda prueba elimina la manzana nuevamente. Esto significa que estas pruebas no están, de hecho, aisladas, porque la segunda depende de que la primera se ejecute rápidamente. Esto significa que si cambias el orden, tu prueba fallará.

haciendo que sea frágil. El problema subyacente, sin embargo, no es la prueba. Las funciones en el módulo de productos cambian el estado global de la parte. Para solucionar esto, podríamos, por ejemplo, restablecer este producto antes de cada ejecución, o podríamos solucionarlo en el lado del código, y, en lugar de escribir en su matriz global de productos, en línea el estado, y con eso, cada consumidor, ya sea una prueba o tu consumidor real, puede crear su propia versión de ámbito del producto, y la prueba vuelve a ser muy importante.

Veamos algunos consejos más para hacer que tus pruebas sean más robustas. Cambiar algo que está fuera de tu alcance es un efecto secundario, por lo que un código robusto en general aísla los efectos secundarios, y las pruebas robustas simulan esos efectos secundarios y otras aleatoriedades. Veamos un ejemplo. Aquí estamos creando un componente que crea un número aleatorio y luego muestra ese número aleatorio al usuario. Crear un número aleatorio es un efecto secundario, así que en el lado de tu código, aislémoslo. Usando React, hay dos formas excelentes de aislar los efectos secundarios. Podemos mover esto aquí dentro de una propiedad de nuestro componente, o simplemente en una función de utilidad que hemos creado. Voy a hacer la segunda opción. Todos los cambios, como puedes ver, es que ahora el generateRandomNumber proviene del exterior, pero esto tiene el efecto de que, por un lado, si alguna vez necesitamos un generador de números aleatorios en otro lugar nuevamente, podemos reutilizar esto. Por otro lado, probar esto se vuelve trivial, porque de repente podemos ver el generateRandomNumber y simular su valor de retorno, y luego asegurarnos de que realmente hayamos mostrado ese número. Aquí, también puedes usar el mismo truco para tu lógica de negocio. Si extraes la lógica de negocio de tus componentes en diferentes módulos, harás que tu lógica de negocio sea reutilizable y tus pruebas más deterministas. Con eso, también puedes probar el módulo extraído de forma aislada, sin tener que renderizar un componente a su alrededor, lo que debería ser más rápido y un poco más fácil. Por último, una fuente común de errores, así como pruebas virtuales, son las condiciones de carrera donde el orden en que las actividades asíncronas regresan puede jugar un papel. Asegúrate de esperar a que todo se resuelva, o prueba diferentes secuencias para tenerlo en cuenta. Las pruebas también deben ser específicas. Si una prueba falla, la causa del fallo debería ser obvia. El nombre de la prueba ya debería darte una buena pista de dónde y qué podría estar fallando, pero si eso no ayuda, el mensaje de error exacto en la consola debería. Para lograr eso, intenta probar solo una parte específica del comportamiento de un componente por caso de prueba. Si bien esto puede no ser siempre posible para pruebas de integración o pruebas de extremo a extremo, en las pruebas unitarias esta configuración debería ser lo suficientemente rápida para configurar varias pruebas con una configuración similar. Entonces, si lo vemos, por ejemplo, en lugar de probar tu flujo principal y diferentes escenarios de error en un solo caso de prueba, como aquí a la izquierda, si los separas, a la derecha, verás algunos beneficios. El primero es que si ahora tienes un fallo, aquí, no sabes qué pruebas están fallando, solo sabes que esta está fallando, porque después de que esa falla, los otros casos de prueba ya no se ejecutan. Mientras que aquí, en el lado derecho, ves que los demás aún funcionan y solo es este comportamiento específico el que está fallando, y eso debería indicarte exactamente dónde buscar tu error. Otro consejo que puede hacer que las pruebas sean más específicas es el uso de afirmaciones específicas o la creación de comparadores personalizados. Mira, por ejemplo, las dos formas siguientes de afirmar que un array tiene tres elementos. En la parte superior, estamos comprobando que la longitud sea igual a tres y obtenemos el error a la derecha, se esperaban tres, se recibieron dos. Si ahora en lugar de eso usas una afirmación de longitud o un comparador, obtienes mucha más información relevante en la consola cuando obtienes

una falla. Y este es solo un ejemplo ficticio, pero el uso de comparadores personalizados es una excelente manera de hacer que las fallas de las pruebas sean más legibles. Y hablando de legibilidad, esa es otra propiedad de las buenas pruebas. Debería ser muy rápido comprender la prueba al leerla, y leer una prueba debería ser básicamente como documentación para el comportamiento esperado de un componente. ¿Y cómo logramos eso? Spoiler alert, porque las pruebas también son código, es prácticamente el mismo consejo que para hacer que tu código sea más legible. Comenzando con una buena nomenclatura clara. Usamos nombres descriptivos. Me gusta seguir el patrón de anidar componentes o características y luego, al final, indicar qué hace cuando se le proporciona Y. Por ejemplo, cierra el modal al presionar la tecla de escape. Además, mantén tus pruebas cortas. Al igual que con tu código, con tu otro código, puedes lograrlo simplemente extrayendo partes de tus pruebas en otras funciones o funciones de utilidad. Veamos esto, por ejemplo. En el lado izquierdo y el lado derecho, ¿cuál es más legible? Spoiler alert, son exactamente las mismas pruebas, solo que en un ejemplo, ya he extraído una funcionalidad común para esperar el seguimiento de un evento, mientras que en el lado derecho, eso todavía está allí, y esta función solo se puede reutilizar en otras partes de la prueba

suite. También hace que la prueba sea mucho más legible. Por último, asegúrate de utilizar la testing biblioteca de pruebas, cualquiera que estés utilizando, al máximo, para hacer que la prueba sea más expresiva, y que tu intención sea más clara para el lector. Si volvemos a este ejemplo de implementar un contador anteriormente, ¿qué es más expresivo, echar un vistazo a una variable de estado con un nombre aleatorio o asegurarse de que el titular haya cambiado de algo a algo más? De manera similar, ¿qué es más expresivo? ¿Un línea de CSS que cambia en la instantánea del componente, o una representación visual de ese cambio antes y después? Por eso no soy muy fan de las pruebas de instantáneas y prefiero utilizar herramientas de testing de regresión visual como Percy en su lugar.

Y las pruebas no solo deben ser legibles, también deben ser rápidas y fáciles de escribir. En la mayoría de los casos, no tiene sentido dedicar más tiempo a escribir tus pruebas que a escribir tu código. Y aunque creo que refactorizar tu código de manera que sea más fácil de probar es generalmente beneficioso para tu base de código porque lo hará más reutilizable, determinista, y menos acoplado, siempre debe haber un equilibrio. Si algo es particularmente difícil de probar, pregúntate a ti mismo, ¿qué tan importante es tener confianza en que esta parte de la aplicación funciona? Por ejemplo, definitivamente dedicaría mucho tiempo a escribir una prueba chapucera e ilegible, en otras palabras, comprometiendo todas las demás propiedades que ya he mencionado para asegurarme de que un usuario pueda iniciar sesión en Spotify. Pero no necesariamente haría lo mismo para asegurarme de que su foto de perfil esté alineada correctamente en Internet Explorer. Otra cosa que a menudo ayuda con esto es moverse hacia arriba o hacia abajo en la pila de testing de Permit. Si algo es realmente difícil de probar en una prueba unitaria, tal vez ignorar un caso límite y testing el comportamiento general en una prueba de integración sea un buen compromiso. Y por último, utiliza la herramienta adecuada para escribir tus pruebas. En el pasado, era extremadamente complicado escribir pruebas para aplicaciones web, pero con herramientas como Cypress con su Depurador Visual o la Biblioteca de Testing, que fomenta el testing desde la perspectiva del usuario, no hay excusa para no tener al menos cobertura para los flujos más importantes de tu aplicación. Entonces, si la herramienta que estás utilizando te está frenando, te animo encarecidamente a considerar cambiar a otra. Y ahora para el último punto. Las pruebas deben ser predictivas. La razón por la que guardé esto para el final es que creo que une todo de manera hermosa. Ya hemos discutido que las pruebas deben darte confianza. Esta propiedad va un paso más allá. Debes ver tu conjunto de pruebas en su conjunto y ser capaz de predecir si tu aplicación funciona o no. Si una prueba falla, esa parte de la aplicación fallará en producción. Si todas las pruebas pasan, la aplicación funcionará en producción. Es un estándar realmente muy alto lograr este nivel de confianza y necesitamos una buena cobertura en todos los frentes: pruebas de integración automatizadas, pruebas de extremo a extremo, pruebas de regresión visual, cualquier tipo de prueba que tengas. Pero una vez que llegues a ese nivel, la forma en que pasas tus días como ingeniero cambiará. Pasarás mucho menos tiempo corrigiendo errores en producción o supervisando tus implementaciones para asegurarte de que no rompan el sistema. Ya no tendrás miedo de implementar los viernes o antes de irte a casa. En cambio, podrás refactorizar cualquier parte pequeña o grande de la aplicación sin miedo. Incluso puedes comenzar a automatizar tareas manuales, como mantener las dependencias actualizadas. Si todas las pruebas pasan, tu código es apto para producción, sin importar si el código fue modificado por ti, otro equipo o incluso un bot. Y eso te brinda infinitas posibilidades. Con eso viene el cambio más importante para nosotros como desarrolladores. Sin necesidad de apagar incendios semanal o incluso diariamente, nuestro trabajo se vuelve mucho menos estresante y tenemos tiempo para enfocarnos en lo que realmente importa.

Es importante. Desarrollar experiencias encantadoras para nuestros usuarios. Gracias. Bueno, preguntaste qué han estado comiendo las personas durante la pandemia, y el 52% de las personas dijeron que pan casero de masa madre, pan o otros proyectos cajún. ¿Estás orgulloso de nuestra audiencia? Sí, mucho. Quiero decir, lo mismo para mí. Así que como has visto todas esas fotos, sí, eso es realmente genial. Tuvimos la misma encuesta en Spotify y los resultados fueron muy muy diferentes. ¿Pero solo para la gente en el Reino Unido o también a nivel internacional? Porque creo que la audiencia internacional lo cambia todo. Sí, en realidad fue para toda nuestra misión, que creo que abarca la oficina de Estados Unidos. Entonces, Nueva York y también Londres y también Estocolmo.

De acuerdo, eso también es realmente internacional, genial. Así que pasemos a las preguntas y respuestas. Tenemos muchas preguntas de nuestra audiencia para ti. Así que vamos a responderlas ahora mismo. Alexius está preguntando que el cliente de escritorio de Spotify falla al cargar la página de inicio con bastante frecuencia recientemente. ¿Tienen alguna herramienta de informes que recopile los bloqueos en el lado del cliente? Sí, no trabajo en el cliente, así que no puedo hablar mucho al respecto. Sé que generalmente realizamos un seguimiento de los bloqueos y cosas así. Tenemos un monitoreo. Realmente no puedo hablar de detalles porque no trabajo en esos clientes. Si deseas informar errores, sé que tenemos diferentes interfaces para eso. Incluso puedes simplemente comunicarte a través de Twitter. Sé que tenemos uno de los mejores servicios de atención al cliente del mundo. Escuchamos eso todos los años. Aparentemente, hay calificaciones para ellos en algún lugar en línea. Son realmente amables y amigables. Genial, sí, y también, olvidé el nombre, pero hay este blog donde también puedes hacer sugerencias, ¿verdad, para Spotify? Sí, exactamente. Hay un foro que también revisamos regularmente. Sí, es posible que hayas escuchado que anunciamos HiFi. Una de las cosas más votadas allí. Eso es muy agradable. Ese flujo de trabajo, realmente darle voz a tu audiencia en lo que sucede. Sí, eso es increíble.

La siguiente pregunta es de Hama. Imaginando que necesitas hacer alguna refactorización o rediseño de componentes, ¿te asegurarías de mejorar las pruebas antiguas antes de la refactorización, o preferirías refactorizarlas y luego mejorar las nuevas pruebas? De acuerdo, estás refactorizando las pruebas. ¿Entendí correctamente la pregunta? No, estás refactorizando o rediseñando componentes. De acuerdo, de acuerdo. Entonces, ¿preferirías pruebas actualizadas o después? Creo que depende. Si tus pruebas te dan una buena idea de si tu componente funciona o no, entonces probablemente puedas seguir adelante con la refactorización del componente primero, porque realmente quieres invertir en lo más importante para tu empresa. La refactorización de pruebas probablemente no es lo que paga las cuentas de tu empresa. Si puedes, comenzaría con el componente. Pero si tus pruebas, digamos, carecen de cobertura para este escenario realmente importante que realiza tu componente, entonces hazlo primero solo para asegurarte de que el comportamiento de los componentes cambie a medida que lo refactorizamos.

Estoy pensando en ello y estoy de acuerdo. La siguiente pregunta es de Sasha. Oh, ¿si vas a compartir tus diapositivas después de la presentación? ¿Qué dijiste? ¿Si vas a compartir tus diapositivas después? Sí, absolutamente. Probablemente ya estén en alguna carpeta. Si no, si olvidé hacerlo, entonces las agregaré muy pronto. Pero sí, todas estarán disponibles en línea, creo. Genial. Genial. Así que Sasha, estate atento. Popplinguje está preguntando, ¿crees que la cobertura de pruebas es inútil? Entonces, ¿qué opinas sobre la cobertura de pruebas? No creo que sea inútil. Creo que es una herramienta muy útil para identificar dónde faltan pruebas. No necesariamente... No creo que tenga sentido decir, okay, necesitamos tener un 90% de cobertura en este nivel y un 78 en aquel nivel. En ese nivel, no creo que la cobertura sea una buena medida de éxito. Pero donde ha ayudado mucho a mi equipo es ver qué partes de nuestro código están bien probadas, qué partes faltan. Y notamos, por ejemplo, que tenemos una cobertura muy buena para esos componentes de muy bajo nivel, pero teníamos una cobertura bastante mala en los contenedores más grandes, todo lo que combina lógica con los pequeños componentes nuevos. Entonces... Las cosas difíciles de probar. Sí, exactamente. Luego tomamos la decisión, okay, necesitamos cambiar esto. Así que agregamos nuestras pruebas de Cypress para probar la integración entre ese tipo de cosas. Y luego tiene sentido mirar dónde están nuestras brechas utilizando los informes de cobertura. Sí. Entonces no estás mirando el porcentaje, sino que estás mirando el informe línea por línea y diciendo, hey, esto está en rojo, pero necesitamos probar este escenario. Exactamente, qué es lo que falta actualmente en lugar de tratar de cumplir algún tipo de relación de porcentaje, algo así. Muy bien, genial. La siguiente pregunta es de Sochiakropka. Algunos afirman que envolver las afirmaciones de prueba en una función disminuye la legibilidad, buscando opiniones al respecto. ¿Qué opinas sobre esto? Okay, no estoy seguro de poder responder a esto. ¿Puedes repetir la primera parte, envolver? Envolver la afirmación de prueba en una función, como extraer la prueba en su propia función,

podría disminuir la legibilidad y te obliga a buscarlas. ¿Y qué opinas de hacer esto? Creo que depende. Así que soy partidario de extraer cosas en funciones que tengan sentido en una unidad en lugar de hacerlo al revés y decir, ya sabes, puedes tener una función de configuración que configure tus pruebas. Creo que está bien, mientras que hacerlo al revés donde tienes todos tus diferentes escenarios en, digamos, un array o algo con diferentes objetos dentro que configuran tu prueba, y luego mapearlos y usar diferentes partes, eso es, creo, donde se vuelve ilegible. Así que trato de abstraer cosas que tienen sentido como una unidad. Si tienes, ya sabes, usuarios que han iniciado sesión correctamente como algo que usas en varios lugares, entonces creo que tiene sentido extraerlo en una función.

Sí, exactamente. ¿Entonces solo lo harías si lo reutilizas? O también, sinceramente, por razones de legibilidad, si es tan largo, ¿verdad, y al mismo tiempo quieres, es solo una cosa secundaria en tu prueba, quieres probar otras cosas también, tal vez eso ya es tu culpa, como, tal vez no deberías hacer eso, deberías tener una prueba separada para cada una. Pero si, en una prueba de integración, también quieres comprobar que el inicio de sesión funciona o algo así, no dedicaría la mitad de la función a ese inicio de sesión, lo pondría en una función separada, solo para que sea más legible y transmitir el mensaje, ¿verdad, entender el punto. Sí. Sí. Entonces, además, si tienes una prueba grande, pero el 80% de eso es configuración para llegar a la página correcta o configurar los data, entonces extrae la configuración, ¿qué es esto, actuar, ACT, ¿verdad, son los tres pasos, y puedes hacer una función, una función C, una función T. Sí, absolutamente. Muy bien. Tenemos tiempo, oh, no tenemos tiempo para una última pregunta, pero afortunadamente, Iris estará en un chat de espátulas donde puedes continuar la conversación, hablar sobre testing, pero desafortunadamente tenemos que dejarte ir ahora. Realmente disfruté hablar contigo y espero verte de nuevo. Espero que vuelvas en nuestra próxima edición. Esperemos. Muchas gracias. Adiós.`