¡No Más Pruebas Inestables!

Rate this content
Bookmark

En esta charla, aprenderás qué son las pruebas inestables, la importancia de las pruebas deterministas, los efectos colaterales de las pruebas no deterministas, los motivos por los que las pruebas pueden volverse frágiles y, finalmente, qué hacer (y qué no hacer) cuando encuentras pruebas inestables

29 min
07 Dec, 2023

AI Generated Video Summary

La charla discute los efectos perjudiciales de las pruebas inestables y la importancia de escribir pruebas deterministas. Proporciona estrategias para identificar y abordar pruebas inestables, incluyendo el uso de reintentos de prueba y tareas de quema en CI. La charla también enfatiza la necesidad de evitar tiempos de espera arbitrarios y manejar dependencias al escribir pruebas de extremo a extremo. Destaca la importancia de ejecutar pruebas en CI y aprovechar herramientas como Cypress Cloud para la repetición y depuración de pruebas. Además, sugiere simular externos para mejorar el determinismo y priorizar el trabajo para abordar las pruebas inestables de manera oportuna.

1. Introducción

Short description:

Estoy aquí en el escenario para hablar sobre No Más Pruebas Inestables. ¿Alguna vez has encontrado un error que funciona en la máquina del desarrollador pero falla en el pipeline de integración continua? Vamos a discutir la importancia de escribir pruebas deterministas.

Estoy muy feliz de estar aquí. Fui el MC los últimos dos años, y ahora estoy aquí en el escenario. Estoy un poco nervioso, pero espero que les guste la charla que preparé para hoy, que se llama No Más Pruebas Inestables. Y quiero preguntarte si alguna vez has estado en una situación en la que encontraste un error, y le preguntaste al desarrollador, y ellos dijeron, funciona en mi máquina. Siempre en llamas, pero funciona en mi máquina. Y entonces piensas, ¿deberíamos desplegar tu máquina para que nuestros usuarios puedan usarla? ¿Pero qué pasa con esa prueba que pasó localmente en tu computadora? Y cuando comenzó a correr en el pipeline de integración continua, comenzó a fallar a veces. Así que si estamos escribiendo las tareas, somos un poco culpables también.

2. Los Efectos Dañinos de las Pruebas Inestables

Short description:

Las pruebas inestables son dañinas y más dañinas que no tener pruebas en absoluto. Disminuyen la confianza en el conjunto de pruebas, aumentan el número de errores no encontrados y aumentan el tiempo de depuración y los costos de ingeniería de software. También aumentan el tiempo de entrega y disminuyen la calidad percibida del software. Las pruebas pueden volverse no deterministas debido a entornos compartidos entre pruebas manuales y automatizadas y tiempos de espera causados por solicitudes de red.

Y si decimos que deberíamos desplegar la computadora del desarrollador en producción, deberíamos también cuidar las pruebas que escribimos para que sean deterministas. Porque una prueba inestable, esta es una analogía que realmente, encontré muy agradable que Brian Mann del equipo de Cypress mencionó que una prueba inestable es como una granada esperando explotar. Y entonces quiero darte mi definición de lo que es una tarea determinista primero, que es que dadas las mismas condiciones iniciales del sistema, cuando una prueba se ejecuta con las mismas entradas, siempre devolverá los mismos resultados, misma salida.

En contraste, la definición de una prueba no determinista es que dadas las mismas condiciones iniciales del sistema cuando la prueba se ejecuta con las mismas entradas, devolverá diferentes resultados. Entonces es esa prueba en la que no hay cambio en el código o de la aplicación o del código de testing y a veces pasa, a veces falla, a veces falla en el primer intento y luego lo intentas de nuevo y pasa y no sabes por qué.

Y quiero decirte que las pruebas inestables, son dañinas y son más dañinas que no tener pruebas en absoluto. Tuve que desvanecer algunas cajas aquí porque no tengo tiempo para hablar sobre todos los efectos secundarios de las pruebas inestables, pero algunos de ellos son que si tienes pruebas inestables, también conocidas como pruebas no deterministas, hay algunos efectos secundarios. Uno de ellos es que disminuye la confianza en tu conjunto de pruebas. Entonces, si tienes un equipo que depende de los resultados de tus pruebas para saber si pueden avanzar con lo siguiente o si tienen que arreglar algo, pero las pruebas fallan, pasan mucho tiempo depurando y no saben y luego cuando descubren qué estaba mal con la prueba, entonces pierdes la confianza.

Y también aumentas el número de errores no encontrados porque cuando los desarrolladores pierden la confianza en el conjunto de pruebas, lo que sucede es que si la prueba está fallando, dirán, ya sabes qué, esta prueba es, siempre están fallando. Entonces, si está fallando, es solo otra prueba fallida. Sigamos adelante. Pero a veces la prueba podría estar encontrando un error real. Y porque no confías en el conjunto de pruebas, simplemente dejas el error. Y quien lo encontrará es el usuario. Ya mencioné, aumenta el tiempo de depuración. Entonces, pasas mucho tiempo tratando de entender por qué la prueba está fallando. Y cuando te das cuenta de que era solo una prueba que no estaba bien escrita, o no era lo suficientemente robusta. Como el tiempo es dinero, también aumenta los costos de ingeniería de software.

Y con las metodologías ágiles, lo que queremos es disminuir el tiempo de entrega para hacerlo lo más corto posible para entregar nuevas funcionalidades a nuestros usuarios. Pero si tenemos pruebas inestables, lo que hacemos es aumentar el tiempo de entrega. Y finalmente, disminuimos la calidad percibida del software que estamos escribiendo. Y hay algunas razones por las que las pruebas pueden ser o volverse no deterministas o inestables. Algunas de ellas es donde cuando compartes entornos entre pruebas manuales y pruebas automatizadas. Entonces, al mismo tiempo que se está ejecutando un conjunto de pruebas automatizadas, por ejemplo, para un pull request que se ha abierto en un entorno que se comparte con alguien que está ejecutando algunas pruebas manuales, alguien cambió la configuración y la prueba automatizada falla. Y cuando vas e investigas, te das cuenta de que fue solo una configuración que alguien cambió manualmente. Otra razón son los tiempos de espera. A veces, debido a las solicitudes de red, las cosas tardan en procesarse. Y harías algo como si usas Cypress, por ejemplo, podrías hacer algo como un Cy.wait, 10,000 milisegundos. Esa no es la forma de hacerlo.

3. Identificar y Abordar las Pruebas Inestables

Short description:

Las pruebas pueden volverse inestables debido a los tiempos de ejecución variables, los diferentes recursos computacionales entre los entornos locales y de CI, los problemas del estado del componente y las dependencias entre tareas. Utilice reintentos de prueba para identificar tareas no deterministas. Cypress proporciona utilidades como los tiempos de puntos de Lodash y la biblioteca grep para etiquetar y ejecutar tareas varias veces. Quemar tareas en CI ayuda a garantizar su estabilidad y evita la introducción de tareas inestables en la suite.

Esto es algo que todavía hará que sus pruebas sean inestables o no deterministas, porque 10,000 milisegundos o 10 segundos pueden funcionar en un caso. Y si tarda 11 segundos, ya no va a funcionar. Y si tarda menos de 10 segundos, entonces estás esperando más de lo que deberías.

También está la razón de local versus integración continua. Cuando estás ejecutando tareas en tu computadora local, tienes diferentes poderes computacionales, recursos computacionales que en CI y esto podría causar inestabilidad también.

Estado del componente. Por ejemplo, que estás intentando interactuar con un botón que aún no está habilitado o un campo de entrada que no es visible o hay alguna animación o transición ocurriendo. Si eres usuario de Cypress, la forma de hacerlo en Cypress, por ejemplo, para un botón que no está habilitado, podrías antes de intentar interactuar con el botón, hacer algo como lo que hago aquí, donde decides obtener el botón, asegurarte de que debería estar habilitado y luego haces clic en él.

Y finalmente, otra razón para que las tareas se vuelvan no deterministas es cuando tienes dependencia entre ellas. Entonces, si por ejemplo, intentas poner un punto solo en la segunda, ya que depende de la primera para ejecutarse, fallará. Y queremos tener tareas independientes entre sí porque entonces vamos a tener resultados deterministas.

¿Y cómo puedes encontrar estas tareas no deterministas o inestables? Una forma de hacerlo es con reintentos de prueba, pero quiero decir que deberías usar reintentos de prueba como una forma de identificar las tareas no deterministas y no como una forma de enmascararlas.

Hay diferentes formas en las que puedes quemar tus tareas antes de hacerlas parte de la suite oficial de tareas. Algunas de ellas, tenía más opciones aquí, pero tuve que cortar algunas diapositivas.

Si eres usuario de Cypress, Cypress viene junto con Lodash, que es una biblioteca de utilidades que tiene muchas funciones de utilidad, y una de ellas es dot times. Entonces puedes envolver tu bloque it, que es tu caso de prueba, dentro de Cypress dot Lodash dot times, y luego, como primer argumento, pasas cuántas veces quieres que se ejecute esta prueba. Y el segundo argumento es la función de devolución de llamada. Tu suite de pruebas estará dentro de la función de devolución de llamada. Por ejemplo, si quiero estar seguro de que mi prueba es lo suficientemente estable, la ejecutaría tres veces, cinco veces, diez veces el tiempo que creas que sería suficiente para asegurarte de que es estable.

Otra forma de hacerlo, si usas Cypress también, soy embajador de Cypress, así que todos los ejemplos que tengo aquí están relacionados con Cypress. Cypress mantiene una biblioteca llamada grep, que te permite añadir etiquetas a tus pruebas como esta, donde añadí una etiqueta llamada at burn, y luego en la línea de comandos, puedes ejecutar tu prueba con cypress run dash dash env grep tags igual al nombre de tu etiqueta. Y luego puedes poner coma burn y el número de veces que quieres que se ejecute esta prueba.

Esto es algo que me encantaría ver a la gente haciendo en CI porque lo que mencioné al principio, no queremos que la prueba solo pase localmente. Queremos verlas pasar en CI también. Así que si las quemamos en CI, podemos estar seguros de que no estamos introduciendo pruebas inestables en nuestra suite.

Muy pronto Cypress lanzará, probablemente a principios del próximo año, creo, una funcionalidad llamada burn in, que quemará inteligentemente tus pruebas si nota que tu prueba es nueva o es una prueba que acaba de cambiar. Entonces, si es nueva, no tiene ningún historial. Y por eso, quieres quemarla antes de hacerla parte de tu suite de pruebas. No quieres simplemente fusionar una nueva prueba si no sabes si es determinista, porque si lo haces y te das cuenta de que es no determinista después, ya es demasiado tarde.

Nuestro equipo comenzará a investigar pruebas inestables.

4. Abordando Tareas Inestables

Short description:

Al encontrar tareas inestables, es importante identificar la causa raíz y solucionarla de inmediato. Si no tienes tiempo para solucionarlo de inmediato, pon en cuarentena la tarea y abórdala más tarde. Otra opción es eliminar la tarea y reescribirla o considerar moverla a un nivel inferior de pruebas para un mejor control y determinismo.

Perderán la confianza y todas esas cosas que ya he mencionado. Aquí hay tres cosas que te animo a hacer cuando encuentres tareas inestables. La primera es identificar la causa raíz y solucionarla de inmediato. No lo dejes para después intentando solucionarlo. Si estás trabajando en una tarea y te das cuenta de que es inestable, intenta identificar por qué es inestable y soluciónalo. Si no tienes tiempo para solucionarlo, mencioné antes que una tarea inestable es más perjudicial que no tener las tareas. Así que si no vas a tener tiempo para solucionarlo de inmediato, ponla en cuarentena. Pon un .skip, abre un problema, ponlo en el backlog y luego mira en el backlog de tareas en cuarentena para que puedas solucionarlas. Y otra opción sería simplemente eliminar la tarea y reescribirla. O incluso intenta escribirla, intenta entender si tiene sentido estar en el nivel donde está, por ejemplo, en las pruebas de extremo a extremo, o si podría ser trasladada a un nivel inferior como las pruebas de componentes donde tienes más control de las cosas. Y entonces, porque tienes más control, tienes tareas más deterministas.

5. Qué No Hacer con las Tareas Inestables

Short description:

No ignores las tareas inestables ni uses tiempos de espera arbitrarios. En su lugar, utiliza utilidades de Cypress como sci.intercept y alias para manejar las solicitudes. Evita depender únicamente de las reintentos de pruebas, ya que solo enmascaran el problema. No debemos aceptar más tareas inestables. Las tareas automatizadas deben ser deterministas y pasar en el entorno de CI. Consulta el contenido sugerido y la presentación en speaker deck. Recientemente he lanzado un curso llamado Cypress de Cero a la Nube. Tiempo para preguntas y conéctate conmigo en https://valmir.dev.

Y luego qué no hacer cuando te encuentras con una tarea inestable. Aquí hay algunos tips de qué no hacer. No las ignores, en primer lugar. No uses algo como sci.wait con un número. Cypress ofrece esta funcionalidad, pero no para que la uses con sci.wait 5,000, 10,000. Te da esta funcionalidad. Así que puedes, por ejemplo, usar sci.intercept para interceptar una solicitud que sabes que va a suceder después de algunas acciones. Y luego cuando llega la solicitud, puedes esperar un alias que le diste a tu intercept. Y tampoco te apoyes solo en los reintentos de pruebas porque solo estarás barriendo el polvo bajo la alfombra. Así que no los uses para enmascarar que tienes tareas inestables. Úsalos para entender que las tienes y que tienes que hacer algo. Si no vas a hacer algo, simplemente bórralas.

Así que el mensaje final que tengo para ti aquí es que no deberíamos estar aceptando tareas inestables más porque la confianza es todo. Y como no te gusta la frase, funciona en mi máquina, entiende que no hay punto en una tarea que pasa que solo funciona en tu máquina también. Las tareas automatizadas, deben ser deterministas y también pasar en el entorno de integración continua.

He dejado aquí algunas sugerencias de contenido para que leas, y la presentación ya está disponible en speaker deck o algo así. Hay una diapositiva donde tengo el enlace. Así que el primero es contenido que escribí en Medium sobre la importancia de lidiar con tareas inestables. También está cómo ejecutar una prueba varias veces con Cypress para demostrar que es estable. Luego está la grabación de la Conferencia de Cypress donde hubo una charla impresionante sobre tareas inestables. Este es el tercer enlace. En el blog de Cypress, hay una etiqueta llamada Flake con un gran contenido sobre cómo lidiar con tareas inestables también. Si eres un usuario de Cypress Cloud, también deberías revisar la documentation. Antes de terminar, recientemente he lanzado un curso llamado Cypress de Cero a la Cloud. Puedes escanear el código QR para una promoción, y las diapositivas se encontrarán en speakerdeck.com slash WLSF82 slash no more flaky tests. Pensé que no lo lograría en menos de 20 minutos. Lo hice, así que tenemos tiempo para preguntas. Y si quieres conectarte conmigo, puedes acceder a https://valmir.dev. Es W-A-L-M-Y-R punto dev. Muchas gracias.

6. Evitando Dependencias y Probando el Flujo de Usuario

Short description:

Al escribir la especificación de extremo a extremo para cubrir un flujo de usuario, es importante evitar las dependencias entre las pruebas. Actualizar a la última versión de Cypress puede ayudar con el aislamiento de las pruebas. La configuración de los datos de antemano se puede hacer a través de APIs públicas, código de aplicación o scripts. Se recomienda probar el flujo de usuario como lo haría un usuario, como combinar las pruebas CRUD en una tarea independiente.

Así que ya hemos visto algunas preguntas que empiezan a llegar en Slido, y sólo quiero hacer una nota rápida. Estoy emocionado por esto porque la última... He estado en tu programa antes, y tú me hacías las preguntas. Sí. Y ahora yo te hago las preguntas. Genial. Y es sobre uno de mis temas favoritos, que son las pruebas inestables en Cypress. Así que podemos entrar en materia. Hay muchas preguntas. Así que vamos a empezar con esta. ¿Cómo evitas las dependencias entre las pruebas cuando estás escribiendo una especificación de extremo a extremo y estás cubriendo un flujo de usuario? Hay diferentes formas. Una cosa que sugeriría, por ejemplo, si eres usuario de Cypress, es actualizar a la última versión porque introdujeron algo llamado aislamiento de pruebas, que básicamente no te permite escribir pruebas dependientes. Y no te animo a que lo desactives, porque las pruebas deberían ser independientes unas de otras. Hay casos en los que necesitarías configurar algunos datos de antemano, y hay muchas formas de hacerlo. Algunas formas que enseño a mis estudiantes, por ejemplo, es si tienes APIs públicas, usas algo como CyDOT request para hacer la solicitud, por ejemplo, una solicitud POST para crear algo que debería estar allí antes de empezar a probar. Y luego llegas al estado que quieres probar de antemano, y lo pones en un gancho antes de cada uno o algo así. Si tienes acceso al código de la aplicación y puedes, sabes, crear una tarea que crea el estado para ti, también puedes hacerlo. Si tienes, no sé, un script de Shell, un script de NPM que siembra la base de datos de antemano, puedes usar CyDOT exec para hacerlo. Pero siempre te animo, y si estás probando un flujo de usuario, como prueba exactamente como un usuario probaría, usaría la aplicación en una prueba. Como hay un caso en el que enseño un caso en el que tienes como un CRUD y tienes una prueba para crear, una para leer, una para editar, una para borrar. Ponlos todos en un bloque it, y va a ser sólo una tarea independiente que prueba completamente el flujo de usuario.

QnA

Manejo de Diferencias de Recursos

Short description:

Una estrategia es configurar las pruebas de forma independiente, incluso si te encuentras en una página diferente. Si una prueba falla debido a una infraestructura inestable, es importante abordar la causa raíz. El uso de entornos efímeros puede ayudar a garantizar la estabilidad y reducir los problemas de configuración. Al tratar las diferencias de recursos entre local y CI, es importante encontrar estrategias para manejar la paralelización y garantizar pruebas consistentes.

Sí. Has tocado un par de, quiero decir, varios puntos realmente importantes allí. Uno de ellos es, obviamente, la gestión de pruebas data y la configuración de tus pruebas de la manera correcta, incluso si te encuentras en la tercera página de un formulario, por ejemplo. No tienes que hacer que la prueba sea la primera página, luego el segundo bloque sea una segunda página. Puedes configurarlos de forma independiente. Así que muchas grandes estrategias que acabas de cubrir allí.

Así que esta próxima pregunta está recibiendo muchos votos positivos es si el código o la infraestructura o la prueba no cambian, pero una prueba falla debido a una infraestructura inestable, ¿considerarías eso una prueba inestable? Tal vez la infraestructura es inestable y esto es lo que debería ser abordado. Y si no puedes, entonces tal vez añadirías algunas salvaguardas en tu prueba para asegurarte de que la infraestructura está en funcionamiento, está respondiendo con lo que esperarías antes de ejecutar la prueba. Pero idealmente, creo que deberías ir a la causa raíz, que es como una infraestructura inestable. Por ejemplo, estoy testing en un entorno que no tiene tanto poder computacional como la producción. Así que levanta un ticket para, ya sabes, añadir más memoria a ese entorno o algo que lo haría más estable. Sí.

Así que hay muchas razones por las que las pruebas pueden fallar, ¿verdad? Podría ser una mala prueba. Podría ser la mala aplicación. Podría ser una API que está caída y podría o podría ser la infraestructura. Y probablemente todos hemos lidiado con entornos de prueba que no están al mismo nivel que nuestro entorno de producción. Correcto. Y eso es una gran lucha. Y entonces tratar de, ser capaz de resolver el problema raíz de la infraestructura, creo es el camino a seguir. Yo no lo consideraría, personalmente, una prueba inestable tampoco. Sí, yo tampoco. Me gusta la idea de usar entornos efímeros donde creas un PR, se crea un entorno efímero solo para ese cambio. Las pruebas se ejecutan contra ese entorno. Cuando terminan, el entorno se cierra. Y entonces, como cuantos más entornos tienes, más problemas tienes porque tienes diferentes configuraciones en diferentes entornos. Así que intenta reducirlo al mínimo que te dará la confianza que te permitirá hacer cambios en producción para que tus usuarios los utilicen. Genial. Genial.

Bien, entonces esta próxima pregunta, ¿cuáles son las estrategias para lidiar con las diferencias de recursos entre local y CI? Así que estábamos hablando de esto con los entornos justo ahora, pero tiende a causar problemas, particularmente a menudo al paralelizar. No sé si entendí exactamente cuál es la estrategia para lidiar con los recursos.

Ejecución de Pruebas en CI

Short description:

Al ejecutar pruebas en CI, es importante considerar las diferencias en la potencia computacional entre la máquina local y el entorno de CI. Analice cada caso individualmente y ajuste los tiempos de espera en consecuencia. Ejecutar solo las partes relevantes de la suite de pruebas localmente antes de enviar a CI puede ayudar a identificar cualquier problema. Considere el uso de variables de entorno o la comprobación del entorno de CI para hacer ajustes. Es crucial confiar en el proceso de CI para las pruebas automatizadas y aprovechar herramientas como Cypress Cloud para la repetición de pruebas y la depuración.

Entonces, supongo que la manera en que lo entiendo es que si ejecuto una prueba en CI y estoy usando una máquina y funciona bien, solo estoy intentando ejecutarla localmente y mi máquina no puede manejar, no tiene tanto poder para ejecutar eso. Entonces, tal vez sea inestable localmente o viceversa. Podría tener mi gran máquina, funciona bien, pero una vez en CI, las máquinas no son lo suficientemente grandes.

Sí. Creo que debería analizarse caso por caso. Realmente, deberías tratar de entender cuál es la causa raíz del fallo. ¿Es porque mi máquina no tiene tanto poder computacional como el CI o viceversa, entonces podrías aumentar algún tiempo de espera, no el peso, 10,000, sino el tiempo de espera. Depende del tiempo de espera, no, y si alcanza ese tiempo antes puedes seguir adelante. Pero diría que sería, lo analizaría en una base caso por caso. Sí. Entonces, creo que parte de ello también depende de cuánto de la suite estás ejecutando localmente, ¿verdad? A veces solo puedes ejecutar parte de la suite en el área en la que estás trabajando actualmente antes de enviarlo a CI.

También he visto potencialmente a personas que pasan una variable de entorno diciendo en qué entorno están, o están comprobando si están en CI o no, y luego pueden ajustar dependiendo. Sí. Sí. Esa es una buena idea. Sí. Pero tiendo a no ejecutar mis pruebas localmente con demasiada frecuencia. Me gusta cambiar y luego enviarlo a CI. Eso es. Como no deberías probar solo localmente porque está en CI, CI es el proceso que te dará la retroalimentación que quieres. No quieres preguntar, Oye, Cecilia, ¿puedes ejecutar las pruebas ahora que he terminado? No, quieres que esto sea automático y ya es automático en CI si tienes el proceso en su lugar. Sí, exactamente. Creo, creo, creo que simplemente refuerza buenos procesos, como dijiste. Y si es como en CI, entonces también deberías, por ejemplo, si eres un usuario de Cypress usar Cypress Cloud. Cypress lanzó recientemente en la versión 13 la repetición de pruebas, que te permite básicamente repetir tu prueba y debug con las herramientas de desarrollo directamente en el navegador. Y entonces puedes entender si hubo un error en la consola, si hubo un fallo de red, o puedes hacer muchas cosas allí. Genial. Genial. Bien. Una pregunta rápida.

Simulacro de Externos y Priorización de Pruebas

Short description:

¿Abogarías por simular externos para mejorar el determinismo? En mi masterclass avanzada de Cypress, enseño a probar la conexión con una API de terceros. Para el resto de las pruebas, simulo las respuestas. Esto permite un mayor control, determinismo y ejecuciones de pruebas más rápidas. La combinación de pruebas de API y la suplantación de red puede simular errores y asegurar suplantaciones actualizadas. Los simulacros también pueden servir como documentación y permitir la escritura de la aplicación de frontend sin que el backend esté listo. Se trata de construir software de alta calidad y priorizar el trabajo.

Estaba pensando un poco en esto también. ¿Abogarías por simular externos para mejorar el determinismo, o siempre prefieres probar en un entorno real? Yo lo haría, por supuesto que lo haría, eso es en realidad algo que enseño en uno de mis cursos, es un curso Cypress advanced. Solo está disponible en portugués por ahora. Pero yo pruebo, creo la aplicación de frontend y consumo una API de terceros. En mi curso, lo que enseño es que pruebas que la conexión funciona. Así que tienes al menos una prueba que asegura que tu código, cuando se integra con una tercera aplicación de parte, funciona. Y luego para todo lo demás, todo lo demás, simulo las respuestas que esta API estaría dándome. Y luego puedo probar la cosa que estoy escribiendo en aislamiento con mucho más control con mucho más determinismo y, y, y las pruebas se ejecutan mucho más rápido también, porque no hay red de por medio. Sí. Creo que ahí es donde la combinación de pruebas de API y la suplantación de red puede ser realmente súper eficiente, ¿verdad? Porque puedes asegurarte de que puedes simular errores. Puedes hacer muchas cosas. E incluso puedes usar eso para asegurarte de que las suplantaciones que usas están actualizadas, ¿verdad? Sí. Sí. Sí. E incluso como, es incluso posible escribir la aplicación de frontend sin tener el backend listo y usar tus simulacros como los requisitos para el backend para, ya sabes, esto es lo que estamos esperando. Sí, exactamente. Es una forma de documentation. Exactamente. Sí. Genial.

Bien. Entonces, esta siguiente, sobre saltarse pruebas al crear un ticket para arreglarlas, cómo luchar contra el producto personas, despriorizando tales tickets cada sprint. ¿De quién es la responsabilidad? En saltarse pruebas, estamos creando para arreglarlas. Entonces, en tu presentación, hablaste de cómo si una prueba es inestable, ya sabes, la pones en cuarentena ¿verdad? Sí. Saltarla. Entonces, ¿cómo combates el instinto de algunos equipos para decir, está bien, están en cuarentena. Ahora eso es deuda técnica. No vamos a tocarlo de nuevo. ¿Cómo consigues que la gente realmente priorice ese tipo de trabajo? Creo que todo se trata de la cultura, ¿verdad? Deberías tener en mente que quieres construir software de alta calidad. Y una forma de hacerlo es que hay muchas cosas que tienes que hacer.

Abordando Pruebas Inestables

Short description:

Es importante probar el software a fondo y abordar cualquier prueba inestable de inmediato. Si se está omitiendo una prueba, es crucial encontrar la causa raíz y solucionarla. Si eso no es posible, poner en cuarentena la prueba y crear un problema. Es esencial asignar tiempo para lidiar con la deuda técnica para evitar que se acumule y se vuelva inmanejable.

Pero una cosa que tienes que hacer es probar que funciona como debería. Y si estás poniendo tus pruebas en cuarentena y no estás lidiando con las pruebas en cuarentena, simplemente elimina las pruebas. Porque si no vas a arreglarlas, no las volverás a activar. Así que realmente se trata de preocuparte por el software que estás escribiendo. Y si la prueba que se está omitiendo es importante, tal vez en algún momento un error pasará porque no se está probando. Y si un error pasó, entonces piensas, oh, ahora tengo que arreglarlo. Así que si tienes esa mentalidad de que voy a... Por eso puse como primer punto, arreglarlo de inmediato. Encuentra la causa raíz y soluciónala. Si no, crea una cuarentena y crea un problema. Pero si estás haciendo eso, lo estás haciendo por una razón. Así que trabaja en eso. Tienes que agregar... En mi trabajo anterior, por ejemplo, solíamos tener como... Creo que era como el 50% del tiempo estaríamos trabajando en características. 20% en correcciones de errores y 30% en deuda técnica. Así que tienes que tener ese espacio para lidiar con esa deuda técnica. Porque si no lo haces, es como una deuda, una deuda financiera. Es exponencial. Cuanto más tiempo lo dejes atrás, en algún momento no podrás pagarlo más.

Cobertura de Pruebas e Interactividad

Short description:

La cobertura de pruebas, incluyendo la cobertura de código y la cobertura de interactividad, puede ser una buena manera de abordar las pruebas inestables. La cobertura de interactividad, ofrecida por Cypress, se centra en cómo los usuarios pueden interactuar con la aplicación. Sin embargo, tener una cobertura del 100% no garantiza un software de alta calidad si no hay afirmaciones en las pruebas.

¿Qué opinas sobre la cobertura de pruebas o la cobertura de código como una forma de intentar hacer frente a esas pruebas inestables también? Creo que es una buena idea, sí. Y de hecho, no sólo la cobertura de código, sino por ejemplo, Cypress va a lanzar también algo llamado cobertura de interactividad, que es... Es similar a la cobertura de código, pero mira a tu aplicación desde cómo los usuarios pueden interactuar con ella. Así que si tienes una página con cinco elementos diferentes que pueden ser interactivos, como dos campos de entrada, un enlace y dos botones, Cypress te dará la capacidad de decir, oh, sólo tienes un 40% de cobertura de interactividad porque sólo estás interactuando con estos dos campos y no con estos otros. Así que creo que es una gran manera de lidiar con ese tipo de cosas. Pero no debería ser como, tengo un 100% de cobertura o un 8%. Esto no significa que tengas un software de alta calidad. Hay equipos que tienen un 100% de cobertura, pero no tienen afirmaciones en sus pruebas. Así que no tienen eso, en realidad. Es como si la prueba estuviera siendo... El código se está ejecutando, pero si estás afirmando o nada, entonces no tienes cobertura, en realidad. Sí. No, eso es realmente interesante. No había oído eso todavía. Así que muy, muy emocionante aprender más sobre esa verificación de interactividad. Nos queda aproximadamente un minuto. Tenemos tiempo para una pregunta más. Así que la siguiente aquí, ¿cómo puedes deshacerte de la mentalidad de llamar a cada prueba fallida una prueba inestable? No pienso así. Realmente miro el fallo. Si piensas que cada prueba fallida es inestable, entonces tienes un gran problema que resolver, en realidad. Tal vez ya estás en un lugar donde tu equipo perdió la confianza en tu conjunto de pruebas. Por eso debemos preocuparnos por el código de prueba tanto como nos preocupamos por el código de la aplicación. Así que para deshacerse de esta mentalidad, siempre prefiero liderar con el ejemplo. Haz las cosas que crees que son correctas. Y entonces verás los resultados y la gente a tu alrededor empezará a verlo. Y si los resultados son buenos, empezarán a seguirte. Genial. Sí. Y qué gran nota para terminar. Así que, sí. Muchas gracias por estar aquí de nuevo, Velma. Demos otra ronda de aplausos. Gracias. Gracias. Muchas gracias. Muy bien.

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.

Workshops on related 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 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.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.