La mayoría de nosotros hemos escuchado que las pruebas deben ser aisladas, componibles o deterministas, pero ¿qué significa eso en la práctica? ¿Cómo se escribe una buena prueba y cómo cambia el resto de tu código una vez que lo haces? ¿Qué efecto tiene en tu experiencia como desarrollador? En esta charla, repasaré algunas propiedades que tienen las buenas pruebas, mostraré cómo podemos escribir pruebas que sigan estas pautas en JavaScript y discutiré cuándo considerar flexibilizar un poco las reglas.
Cocina de Pruebas: Una Receta para Buenos Tests
Video Summary and Transcription
Iris, una ingeniera de software, comparte su viaje en la cocina e invita a otros a compartir recetas en Twitter. Discute las pautas de prueba, enfatizando la importancia de las pruebas automatizadas que inspiran confianza y se ejecutan todo el tiempo. Iris brinda consejos para pruebas más rápidas y efectivas, incluyendo la ejecución de pruebas en paralelo y enfocándose en el comportamiento. También destaca la importancia de hacer pruebas robustas, legibles y mantenibles. Finalmente, Iris enfatiza el valor de las pruebas, las pruebas predictivas y las preferencias del público en el desarrollo de software.
1. Introducción a Iris y su viaje culinario
Soy Iris, una ingeniera de software de Austria, actualmente viviendo en Londres. Durante la pandemia, he estado cocinando mucho y probando diferentes recetas de todo el mundo. Si tienes alguna receta interesante o plato de tu país de origen, compártelo conmigo en Twitter.
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
2. Directrices de Pruebas y Automatización
Y cuando no cocino, desarrollo productos para nuestros usuarios en Spotify. Somos uno de los servicios de transmisión de audio más grandes del mundo con más de 70 millones de canciones y casi 350 millones de usuarios activos mensuales. Vamos a sumergirnos en las directrices. Kent Beck enumera 12 propiedades de las pruebas. Las pruebas deben inspirar confianza, permitiéndote refactorizar tu aplicación sin miedo. Las pruebas deben ser automatizadas y ejecutarse sin intervención humana, lo que permite a los equipos trabajar de forma autónoma e iterar rápidamente. Las pruebas automatizadas deben ejecutarse todo el tiempo, desde el desarrollo hasta la implementación.
3. Tips for Faster and More Effective Testing
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. Pero ¿cómo podemos hacer que nuestras pruebas sean rápidas? En primer lugar, ejecútalas en paralelo y vuelve a ejecutar solo las pruebas relacionadas con los archivos que has cambiado. Simula las dependencias lentas y ejecuta las pruebas en el entorno adecuado. Al escribir pruebas, concéntrate en el comportamiento del sistema bajo prueba y prueba desde la perspectiva del consumidor. Esto te permite cambiar la estructura interna sin afectar las pruebas.
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
4. Testing Behavior and Properties of Good Tests
Para probar el comportamiento de tu componente, verifica el texto que se muestra a los usuarios. Simula el comportamiento del usuario en lugar de llamar directamente a las propiedades de los componentes de React. Las pruebas buenas deben ser deterministas, aisladas y componibles. Las pruebas deterministas siempre producen los mismos resultados dados los mismos inputs. Las pruebas aisladas no dependen entre sí y pueden ejecutarse en cualquier orden. Las pruebas robustas son autosuficientes y no fallan al azar. Hacer que el código subyacente sea más robusto ayuda a crear pruebas más robustas.
5. Resetting Global State for Isolated Tests
Si tienes que cambiar estados fuera de tu alcance, restablece los cambios en tu estado global antes y después de cada prueba. Por ejemplo, si tienes un módulo de productos que escribe en un almacenamiento global de productos, asegúrate de que las pruebas estén aisladas y no dependan entre sí.
6. Making Tests More Robust
Las funciones en el módulo de productos cambian el estado global de la parte. Para solucionar esto, podríamos restablecer el producto antes de cada ejecución o solucionarlo en el lado del código. Veamos algunos consejos más para hacer que tus pruebas sean más robustas. Cambiar algo fuera de tu alcance es un efecto secundario, por lo que un código robusto aísla los efectos secundarios. Aislemos los efectos secundarios en un componente de ejemplo que crea un número aleatorio. Extrae la lógica de negocio de los componentes en módulos diferentes para que sea reutilizable y las pruebas sean más deterministas. Asegúrate de esperar a que todo se resuelva y prueba partes específicas del comportamiento de un componente por caso de prueba. Utiliza afirmaciones específicas o crea comparadores personalizados para pruebas más específicas.
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
7. Making Tests Readable and Maintainable
El uso de comparadores personalizados es una excelente manera de hacer que las fallas de las pruebas sean más legibles. Las pruebas buenas deben ser rápidas de comprender y servir como documentación para el comportamiento esperado. La nomenclatura descriptiva y mantener las pruebas cortas contribuyen a la legibilidad. Extraer funcionalidades comunes en funciones de utilidad mejora la legibilidad y reutilización.
8. Importance of Testing and Predictive Tests
Por último, asegúrate de utilizar la 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. Las pruebas no solo deben ser legibles, también deben ser rápidas y fáciles de escribir. Siempre debe haber un equilibrio entre el tiempo dedicado a escribir pruebas y escribir código. Utiliza la herramienta adecuada para escribir tus pruebas. Las pruebas deben ser predictivas, lo que te permite refactorizar sin miedo y automatizar tareas manuales. Lograr un alto nivel de confianza en tu conjunto de pruebas cambiará la forma en que trabajas como ingeniero, reduciendo el tiempo dedicado a corregir errores y supervisar implementaciones.
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.
9. Delightful Experiences and Audience Preferences
Desarrollar experiencias encantadoras para nuestros usuarios. Gracias. Durante la pandemia, el 52% de las personas han estado disfrutando de pan casero de masa madre, pan o otros proyectos cajún. Los resultados de la encuesta en Spotify fueron muy diferentes, reflejando la naturaleza internacional de nuestra audiencia.
QnA
Q&A sobre bloqueos y refactorización de pruebas
Alexius está preguntando sobre bloqueos en el cliente de escritorio de Spotify. Aunque no trabajo en el cliente, sí realizamos un seguimiento de los bloqueos y tenemos un monitoreo en su lugar. Si deseas informar errores, puedes comunicarte con nuestro soporte al cliente en Twitter o a través de nuestro foro. Valoramos la opinión de nuestra audiencia y hemos implementado sugerencias a través de nuestro anuncio de HiFi. En cuanto a la refactorización o rediseño de componentes, depende de si tus pruebas te dan una buena idea de la funcionalidad del componente. Si es así, puedes priorizar la refactorización del componente primero. Sin embargo, si hay escenarios importantes que no están cubiertos por tus pruebas, es mejor actualizar las pruebas antes de la refactorización.
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.
Test Coverage and Wrapping Test Assertions
Estoy de acuerdo en que la cobertura de pruebas no es inútil. Ayuda a identificar pruebas faltantes y resalta áreas del código que están bien probadas o que carecen de cobertura. Por ejemplo, descubrimos que mientras nuestros componentes de bajo nivel tenían una buena cobertura, nuestros contenedores más grandes tenían una cobertura deficiente. Para solucionar esto, agregamos pruebas de Cypress para probar la integración entre estos componentes. Al enfocarnos en lo que falta en lugar de apuntar a un porcentaje específico, podemos mejorar efectivamente nuestra suite de pruebas. Otra pregunta planteó el problema de envolver las afirmaciones de prueba en funciones, lo cual algunos afirman que puede disminuir la legibilidad. Sin embargo, necesito más información para dar una respuesta definitiva.
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,
Extracting Functions and Improving Readability
Creo que depende. Soy partidario de extraer cosas en funciones que tengan sentido en una unidad. Si tienes algo que usas en varios lugares, entonces extráelo en una función. Por razones de legibilidad, si la prueba es larga y también quieres probar otras cosas, ponlas en una función separada. Además, si una prueba grande es principalmente configuración, extrae la configuración en una función separada.
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.`