Pruebas: Haz más con menos

Hola a todos. Gracias por venir. Mi charla trata sobre hacer más con menos en las pruebas, y será un enfoque práctico sobre cómo puedes probar tu aplicación Node.js.

Primero, intenta responder la pregunta de si tu código está bien probado. Pero sé honesto. ¿Te sientes cómodo desplegándolo automáticamente un viernes por la noche y simplemente irte a casa? ¿Quién puede levantar la mano? Genial. Tenemos algunas personas valientes aquí en la sala. Bueno. Pero, ¿tu canal de lanzamiento siempre se mantiene tan verde como tu árbol de Navidad? También es importante. Eso está genial, chicos. Tal vez la próxima vez hagamos una charla juntos. Aprenderé de ustedes.

Pero antes de que muchos equipos lleguen a eso, pueden responder sí a estas preguntas, necesitan pasar por algunos caminos e implementar algunas cosas. Entonces, ¿cómo te aseguras de que estás avanzando en la dirección correcta? Para eso existen las llamadas métricas Dora, que significa investigación y algo de DevOps. Básicamente te ayuda a entender qué tan bueno es tu equipo o la empresa en términos de rendimiento y velocidad, es decir, qué tan bueno eres en lanzar software.

Tiene cuatro métricas clave, y tres de ellas se ven directamente afectadas por las buenas pruebas. La primera es la frecuencia de despliegue. Básicamente mide con qué frecuencia tu equipo despliega con éxito en producción. Puedes imaginar que si aún tienes pruebas manuales, espero que no, pero algunas compañías aún tienen pruebas manuales, no puedes desplegar con mucha frecuencia. Probablemente despliegues una vez cada dos semanas o una vez al mes. Idealmente, deberías desplegar bajo demanda. El tiempo de entrega para el cambio. Las pruebas también tienen un gran impacto en esta métrica, porque incluso si tienes pruebas automatizadas, imagina que tienes pruebas de extremo a extremo muy inestables y lentas. Esto significa que cada vez que haces push al master, cada vez que tu canal de despliegue comienza, puede llevarte horas, y si falla, puede llevarte días o incluso semanas obtener un canal de despliegue en verde. Nuevamente, eres muy lento. Y por último, pero no menos importante, donde las pruebas juegan un papel importante es la tasa de fallos en los cambios. Básicamente mide con qué frecuencia tu despliegue causa algún problema en producción, y tiene una conexión directa con la cobertura de pruebas. Pero no la cobertura de pruebas como mides, oh, el 80% de mis líneas están cubiertas. Estoy feliz. No. Esta es la cobertura real.

¿Estás probando las cosas correctas? ¿Estás cubriendo los flujos que aportan más valor a la empresa? Entonces, ¿cómo puedes abordar tus pruebas, cómo puedes escribir menos pruebas y obtener una mayor confianza? Así que, nuevamente, supongo que al menos has escuchado, o incluso tal vez ya estás aplicando el trofeo de pruebas. Se promueve y se hizo popular después de que Kent C. Dodds, creo, escribiera un artículo al respecto y ahora imparte capacitaciones al respecto. Pero básicamente, la idea principal del trofeo de pruebas es ayudarte a enfocarte en escribir las pruebas correctas. Si ves que cada prueba tiene su costo y te brinda cierto nivel de confianza, y tiene cierta velocidad.

Entonces, las pruebas unitarias tienen un costo muy bajo, ¿verdad? Es muy fácil escribir pruebas unitarias, especialmente hoy en día que tenemos GPT, puedes preguntar y generará pruebas unitarias automáticamente. Te brindan, diría yo, una confianza promedio porque si solo tienes pruebas unitarias, es posible que no sea suficiente para implementar automáticamente, pero la velocidad es muy alta. Puedes ejecutarlas más rápido. Por otro lado, las pruebas de extremo a extremo. El costo para ellas es muy alto porque no solo es el costo de escribir la prueba de extremo a extremo, sino también mantenerla a largo plazo. Necesitas una infraestructura especial, necesitas un entorno especial donde debes ejecutarlas, ese entorno debe ser estable. Pero te brinda una confianza muy alta. Si tu prueba de extremo a extremo está en verde, tienes mucha confianza de que todo funciona como se espera, pero la velocidad es baja, ¿verdad? En algún punto intermedio están las pruebas de integración. El costo para ellas es muy similar al de las pruebas unitarias, te brindan una muy buena confianza. Diría que, en mi experiencia, solo tener pruebas de integración a veces es suficiente y puedes prescindir de las pruebas de extremo a extremo y su velocidad sigue siendo alta. Y puedes ver que en este trofeo de pruebas, se enfatiza que la cantidad de pruebas de integración debe superar la cantidad de pruebas de extremo a extremo y pruebas unitarias.

Entonces, ¿cómo abordas esto? Paso número cero. ¿Recuerdas? Puedes habilitar linters estáticos y verificaciones de tipo. Es gratis, ¿verdad? Todos deberían hacerlo. Paso número uno. Comienzas escribiendo pruebas de integración. Intentas escribir pruebas de integración para cada flujo feliz y no feliz. Luego verificas la cobertura de tus pruebas. Identificas, ok, tal vez hay algunos casos de borde para los cuales no tiene sentido escribir una prueba de integración, puedes escribir una prueba unitaria para cubrirlos. O tal vez dentro de tu aplicación, hay algún código reutilizable que utilizas en varias partes. Entonces, tal vez lo consideres como una biblioteca. Entonces, también tiene sentido escribir pruebas unitarias para eso. Y por último, en términos de pruebas, habla con tu equipo de negocios, habla con tu producto. Pídeles que identifiquen los flujos críticos para el negocio.

Entonces, los flujos que, si no funcionan, la empresa pierde millones por segundo. Y solo cubre esos flujos críticos para el negocio con pruebas de extremo a extremo. Y luego, seamos honestos, no todo es posible de probar. Aún así, necesitas tener una buena observabilidad en producción. Debes tener métricas, debes tener registro, debes hacer un seguimiento de tus eventos, como eventos de productos. Así puedes identificar de inmediato cualquier anormalidad si implementas algo incorrecto.

En esta charla, nos vamos a enfocar en los pasos uno, dos y tres. Como dije, esta charla se centra en las pruebas de aplicaciones Node.js. Esta es la arquitectura o estructura típica de una aplicación Node.js, cómo funciona. Tienes un navegador, tienes una aplicación del lado del cliente que se ejecuta en el navegador. Realiza una solicitud. La solicitud pasa por una infraestructura en la nube que realiza algunas cosas como la terminación HTTPS, tal vez autenticación, límite de velocidad, muchas cosas. Y luego la solicitud llega a tu aplicación Node.js. Digamos que es una aplicación Express. Tienes una cadena de middlewares que analiza y enriquece la solicitud. Por lo general, tienes, los llamo middlewares de infraestructura. Esos middlewares que realmente no pertenecen a tu aplicación, pero simplemente hacen posible que tu aplicación se ejecute en el entorno. ¿Entiendes? Hacen muchas cosas como analizar las solicitudes entrantes, autenticar al usuario, tal vez habilitar la localización, y así sucesivamente. Y luego, finalmente, la solicitud llega al código, al recuadro blanco, en realidad al código que escribiste, al código que contiene la lógica del negocio. Y este código necesita obtener datos de algún lugar para hacer algunas manipulaciones, ¿verdad? Realiza una serie de llamadas a la API o tal vez llamadas directas a la base de datos. Esas llamadas a la API nuevamente pasan por alguna infraestructura en la nube hacia las API. Y luego, cuando los datos regresan, haces algo con estos datos, como devolver el JSON o tal vez renderizar el HTML en el lado del servidor y luego devolverlo al navegador. Este es el tipo de aplicación que vamos a intentar probar. Si escribes la prueba unitaria, en realidad, con cada prueba unitaria, cubres este pequeño rectángulo azul. Espero que puedas verlo. Entonces, necesitas escribir muchas pruebas unitarias para cubrir todo el espacio en blanco. Pero aún así, no podrás cubrir la interacción entre los recuadros. Entonces, podemos pensar cómo podemos escribir pruebas de integración que nos ayuden aquí. Este es el escenario típico de la prueba de integración. Dado que tenemos una solicitud entrante, una solicitud HTTP, por ejemplo, desde el navegador, la aplicación realiza llamadas API especificadas y devuelve la respuesta esperada.

Simulas cómo tu code interactúa con los clientes de API, y luego haces una afirmación de que la respuesta del controlador de ruta se ve como se espera. Es un buen enfoque, pero puedes perder algunas cosas importantes. Entonces, si tienes una cadena compleja de middlewares, si tus middlewares están haciendo algo que es muy importante para ti, es posible que desees incluir esos middlewares y clientes de API en la cobertura de pruebas.

Esto es lo que llamo pruebas de integración de caja negra, porque este tipo de prueba prueba toda la aplicación Node.js como una sola pieza. No te importan los detalles de implementación internos. La diferencia principal aquí es que simulas la solicitud HTTP entrante. Simulas todas las solicitudes HTTP salientes que tu aplicación Node.js puede hacer a la API externa. Luego, escribes una afirmación sobre la respuesta esperada. En este caso, tienes mucha más confianza de que todo funciona como se espera, incluso incluyendo la cadena de middlewares.

Pero a veces puede ser muy difícil de crear, porque en mi experiencia, esos middlewares de infraestructura pueden realizar, por ejemplo, muchas llamadas a la API por sí mismos. O realmente no sabes qué está sucediendo dentro de esos middlewares de infraestructura. Entonces, no simularlos puede hacer que tu prueba sea tan compleja que pasarás más tiempo configurando toda la infraestructura requerida para que se ejecute en lugar de simplemente enfocarte. Entonces, depende de tu situación. Si tus middlewares de infraestructura no son tan complejos, inclúyelos. De lo contrario, puedes excluirlos.

Y podrías pensar, como, okay, ya estoy usando pruebas de navegador. Tengo una aplicación del lado del cliente. Ya estoy usando, como, no sé, Cypress o playwright para ejecutar mis pruebas de interfaz de usuario en el navegador. ¿Puedo también incluir las pruebas de mi aplicación Node.js en la misma suite de pruebas? Bueno, técnicamente puedes. Entonces, básicamente, puedes iniciar la solicitud a tu aplicación Node.js desde el navegador y escribir afirmaciones en el navegador, como dentro de Cypress o playwright. La mayor desventaja de este enfoque es que necesitas ejecutar tu aplicación Node.js como un proceso separado. Por lo tanto, la infraestructura para este tipo de prueba es más compleja en comparación con las anteriores. Pero aún así, es mucho mejor que las pruebas de extremo a extremo. Porque en las pruebas de extremo a extremo, incluyes todo. Y si algo falla, como si algo está mal con la infraestructura en la nube en tu entorno de pruebas o si otro equipo implementó un servicio de API con errores, tu prueba fallará.

Entonces, algunas conclusiones clave. Primero que nada, aprende o adopta la estrategia del trofeo de pruebas. Es un buen enfoque. Te guiará y te ayudará a enfocarte en escribir la prueba correcta en el momento adecuado. Una sugerencia propia, comienza con pruebas de integración. Escribe tantas pruebas de integración como sea posible y luego cubre las partes faltantes con pruebas unitarias. Nuevamente, estamos hablando de aplicaciones. Por supuesto, si estás desarrollando una biblioteca, probablemente las pruebas de integración sean la elección correcta allí. Lo siento. Las pruebas unitarias son la mejor elección allí.

Y luego, en la medida de lo posible, intenta reducir la cantidad de pruebas de extremo a extremo. Puede parecer, especialmente al principio cuando recién creas una aplicación, que es la forma más fácil de probar toda la aplicación. Pero cuanto más las mantengas o cuanto más madura sea tu aplicación, más tiempo necesitarás mantenerla y más problemas causarán. Y por último pero no menos importante, no confíes en tus sentimientos. Intenta medir. Hay muchas herramientas que puedes integrar en tu canal de implementación y que medirán cómo van tus métricas y si cambiar la forma en que escribes pruebas tiene un impacto positivo o no.

Y algunas herramientas que personalmente uso cuando escribo pruebas. Frameworks de prueba como Jest, una elección muy obvia. Pero recientemente también estoy usando VTest, que es más rápido. Para simular llamadas a API de terceros, uso Knock. Si necesito simular la llamada HTTP entrante a mi aplicación Node.js, uso SuperAgent. El mock HTTP conocido es un módulo muy útil. Si quieres escribir pruebas de integración enfocadas o pruebas que se ejecuten dentro del framework Express, puedes usar este módulo para simular la solicitud y respuesta de Express. Y también puedes usar Cypress o Playwright para pruebas en el navegador. Así que muchas gracias. Espero que esto genere algunas ideas y te brinde algunas direcciones sobre cómo puedes mejorar tu código. Definitivamente puedes hacer más con menos. Gracias.

¿Qué opinas sobre simular servicios de terceros en pruebas de extremo a extremo? Creo que todo lo que no posees y todo en lo que no confías debería ser simulado. Por lo tanto, no debes confiar en la implementación real de un servicio de terceros porque generalmente son poco confiables. Pueden fallar en el momento en que deseas implementar tu aplicación. Así que no quieres depender de ellos.

De acuerdo. Interesante. Habría pensado que querrías saber si podemos depender de ellos. ¡Así que es un poco contradictorio para mí! Y esto es interesante. Aparentemente, porque no entiendo del todo qué es una prueba empaquetada. De acuerdo, sí. Sí, así que tengo... Tal vez puedas explicarme qué es una prueba empaquetada, ya que no lo sé. Entonces, una prueba empaquetada es una prueba de contrato. Básicamente, cada vez que simulas algo, eventualmente necesitas verificar si tus simulaciones están actualizadas con la implementación real de la API. Entonces, la prueba empaquetada te permite tener un contrato entre tu aplicación Node.js y las API aguas abajo, y puedes verificar si este contrato sigue siendo válido. Y si el contrato sigue siendo válido, significa que tus simulaciones siguen siendo válidas. Entonces, la respuesta corta es que si tienes una prueba empaquetada en tu canal de implementación, úsala, pero es bastante difícil de configurar. Pero es un buen enfoque. De acuerdo. Así que es un... Es un paso avanzado, sí. No es fácil de seguir... Sí, no es tan fácil. ¿Qué opinas sobre las pruebas de snapshot? Pruebas de snapshot. No lo mencioné, pero cada vez que haces una afirmación sobre la respuesta, personalmente me gusta escribir una prueba de snapshot. Te brinda una gran confianza de que sabes exactamente qué está devolviendo tu aplicación. Entonces, incluso si algo cambia y no esperas que afecte tu respuesta, el snapshot te lo indicará de inmediato, diciéndote que hay una diferencia.

Pero podría darte muchos falsos positivos. Sí, puede haber algún cambio insignificante que no sea relevante, pero la prueba de snapshot podría fallar. Personalmente lo uso, pero sé que, por ejemplo, a los miembros de mi equipo no les gusta porque a menudo, necesitas actualizar las simulaciones. Y a veces las actualizas solo porque están rotas y realmente están rotas. Sí. Pero... Sí, eso es interesante. Las pruebas de snapshot siempre son una bendición y una maldición.

Siguiente pregunta para ti. ¿Cómo mantienes tus simulaciones si las API externas cambian con el tiempo? Sí. Entonces, las API externas en esta charla suelen ser las API internas de tu empresa. Por lo general, en la empresa, hay un acuerdo de que no se deben hacer cambios incompatibles hacia atrás. Entonces, idealmente, tus simulaciones deberían seguir siendo válidas para siempre. Si no confías en los otros equipos de tu empresa, entonces puedes implementar la verificación. Pero en mi experiencia, durante muchos años, si todos los equipos siguen esta regla de que las API no pueden tener cambios que rompan, por lo general, tus simulaciones se mantienen actualizadas y siguen siendo confiables. Entonces, solo cambias las simulaciones si comienzas a utilizar una nueva función. Luego actualizas la simulación para que comience a proporcionar esta nueva función. Pero si no dependes de esa nueva función, no necesitas actualizar la simulación. Entonces, pueden permanecer... Oh, entiendo. ¿Entonces es más estable de lo que la gente piensa? Sí. En mi experiencia, sí. Mucha gente le tiene miedo. Pero en mi experiencia, es bastante estable. Pero nuevamente, si todos siguen la regla de que las API no deben contener cambios incompatibles hacia atrás.

Vamos a comenzar una guerra con esta pregunta, tal vez. Cypress o Playwright? De acuerdo. Solo se permite una respuesta de una palabra. Sin explicaciones.

Simplemente diremos. De acuerdo. Bueno, mi preferencia personal reciente es Playwright porque siento que es mucho más fácil de configurar. Pero eso es una preferencia personal. Soy un gran fan de CodeGen. En el pasado, tuve buenos momentos escribiendo pruebas con Cypress, así que no tengo nada en contra de Cypress. CodeGen también es muy bueno en Playwright. Puedes simplemente hacer clic y obtener las pruebas. Ahorra mucho tiempo al escribir pruebas. Y puedes hacer que la máquina lo haga por ti.

¿Qué hay de las pruebas manuales? ¿Y tener pruebas manuales como parte del sistema? Bueno, creo que en el mundo moderno donde cada empresa intenta lanzar nuevas funciones tan a menudo como sea posible, no veo que debas tener pruebas manuales en tu flujo de trabajo. Si tienes algo que no tiene sentido automatizar, puedo imaginar que sería mejor crear un interruptor de función para ello, de modo que no se exponga directamente al usuario final, implementar en producción, habilitarlo para algunos mejores probadores limitados y hacer pruebas manuales en producción. Pero no permitas que las pruebas manuales bloqueen tu implementación. Externaliza tus pruebas manuales a los usuarios. Sí, tus usuarios pueden ser tus mejores probadores, ¿verdad? Supongo que si puedes implementar rápidamente de nuevo, puedes solucionar lo que sea que se encuentre. Sí. Si tienes monitoreo, entenderás de inmediato que este usuario tiene algunos problemas, puedes crear una solución y implementarla más rápido.

¿Qué monitoreo? Esta es mi propia pregunta. Observabilidad. ¿Qué herramientas de monitoreo usarías en tu flujo de trabajo? En este momento, en eBay usamos una nube privada, por lo que tenemos algunas herramientas propietarias. Pero antes de eso, por ejemplo, usaba Datadog. Es una herramienta muy robusta. Te dice todo sobre lo que está sucediendo con tu aplicación Node.js, por lo que tienes una comprensión clara de lo que está sucediendo. Tienes todas las métricas. Sí. Excelente.

Luego, esto es interesante. Hacer pruebas de integración primero se interpondría en el camino de hacer TDD. ¿Cuál es tu opinión sobre TDD? Bueno, seré honesto aquí. Intenté TDD durante los hackathons y talleres, pero nunca lo hice en la vida real.

Quiero decir, cuando hago mi trabajo diario. Bueno.

Tengo curiosidad. Nuevamente, la gente no puede ver esto, pero ¿cuántas personas están haciendo TDD? Wow, hay un grupo de personas. Bueno, veo a alguien levantando la mano, pero estoy seguro de que no está haciendo TDD. Lo estaban llamando. Necesitamos ver el código de las personas para comprobarlo. Escucho a mucha gente decir que lo están haciendo. Hasta que llega una fecha límite. Eso es muy gracioso.

¿Cuánta cobertura de código es suficiente? No quiero decir un número concreto. O cómo definir qué probar y qué no es la segunda parte de eso, así que tal vez eso sea mejor. Sí, necesitas entender el producto, ¿verdad? No creo que la cobertura de las pruebas pueda responderse solo desde un punto de vista técnico del producto. Entonces, si entiendes el producto, si entiendes cómo los usuarios utilizan el producto y cómo las empresas ganan dinero o algo así con este producto, podrás entender mejor qué flujos son más importantes y qué flujos deben ser cubiertos por las pruebas. Creo que eso tiene más sentido que simplemente cubrir el 80% o el 100% de las líneas. Eso no tiene sentido. Todos ustedes lo saben. Sí, puedes escribir algunas pruebas estúpidas que te darán una cobertura del 100%, pero no demostrarán nada. Ah-ha, de acuerdo.

Veo que hay bastantes preguntas sobre el porcentaje. Creo que eso se debe a que a menudo nos dicen los líderes de equipo que debemos tener cobertura. Diría que el porcentaje no debería ser el objetivo, pero nuevamente, por mi experiencia, cuando comienzas a escribir pruebas de integración, naturalmente obtienes alrededor del 70% al 80% de cobertura, naturalmente no necesitas hacer un esfuerzo adicional. Y luego, si realmente necesitas agregar más cobertura, si hay algunos casos extremos que aún deseas cubrir, simplemente escribe pruebas unitarias. Si te hace sentir más seguro al lanzar, simplemente escribe esas pruebas. Creo que respondiste un poco esto al comienzo de tu charla, pero podría valer la pena recapitular aquí también. ¿Cómo vendes las pruebas a los PM o a las empresas que están luchando? Bueno, para ellos, vendo las regresiones. A ningún producto le gustan las regresiones. Cuando lanzan algo, una nueva función, y algo más se rompe, ¿verdad? No les gusta, así que generalmente las pruebas son tu arma contra las regresiones. Esa es una de las formas en que puedes venderlo.

Significa que inviertes un poco más de tiempo ahora, pero las otras características que se desarrollarán en tres meses, en medio año, gastarás menos tiempo porque no necesitarás luchar contra las regresiones. Rompe intencionalmente las cosas. Así que ellos dicen, mira, sé que parece que las cosas se están rompiendo mucho últimamente, pero tengo una solución. Simplemente vamos a probar más y mágicamente funciona. Así que supongo que sí, no pueden ver el code con suerte. Mientras no sea uno de esos TPM, estamos bien. Una bonita mentira.

Veamos. Esto también es interesante. ¿Cuándo, en tu opinión, es el mejor momento para ejecutar automáticamente las pruebas? Porque veo que algunas personas lo hacen en el commit, o en los hooks pre-commit, y en el push, justo antes de ir a producción. Entonces, ¿cuándo deberían ejecutar las pruebas las personas? ¿O incluso qué pruebas se ejecutan cuándo? Bueno, si tus pruebas son rápidas, puedes ejecutarlas sobre la marcha. Tan pronto como cambies el code, puedes ejecutar la prueba de inmediato. Lo que solemos hacer en nuestro equipo es ejecutar pruebas en cada solicitud de extracción. Siempre ejecutas la prueba antes de hacer push al code. Es obvio. Y luego ejecutas la prueba cuando tienes una solicitud de extracción, porque si las pruebas de la solicitud de extracción fallan, no tiene sentido que otros pasen tiempo revisando esa solicitud de extracción. Y luego, por supuesto, ejecutas la prueba en tu canal de implementación. Estos son los momentos adecuados. La pregunta es cuándo necesitas ejecutar automáticamente las pruebas. Tan pronto como tengas las pruebas, asegúrate de que se ejecuten automáticamente, para que no las olvides. Incluso si haces un commit, como el viernes por la tarde y te vas a casa, estás 100 por ciento seguro de que la prueba se ejecutará. De acuerdo, asegúrate de que sea automático. Sí. Eso es todo. Sí. Así nadie tiene que presionar un botón y luego estamos seguros. Sí. Fantástico.

Muy bien. Creo que eso es probablemente todo el tiempo que tenemos para preguntas hoy. Así que demos otra ronda de aplausos a Eugene. Gracias. Y puedes volver y disfrutar de tu día. Muchas gracias, Eugene. Gracias. Que tengas un buen día. Adiós.