¡No Más Pruebas Inestables!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

¿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.