Pruebas de extremo a extremo para API: Ahorrando Nervios y Horas

Pero primero un poco sobre mí. Soy un desarrollador, que trabaja principalmente con TypeScript y JavaScript en estos días, es decir, con Node.js, y especialmente con el backend. En uno de mis últimos proyectos, teníamos un backend escrito en NestJS, y tuvimos muchos problemas para probarlo, especialmente cuando necesitábamos cambiar alguna funcionalidad. Así que intentamos pasar eventualmente a las pruebas de extremo a extremo, y eso es de lo que trata mi charla.

En este momento, trabajo en una empresa de Unity, y todo se trata de diversión y juegos y cosas así, pero trabajo en el departamento de publicidad, por lo que tenemos muchos servicios tanto en el frontend como en el backend, y por supuesto, necesitamos probarlos cuidadosamente. Así que vamos al grano, no tenemos mucho tiempo. Cuando hablamos de pruebas de API, ¿a qué nos referimos normalmente? En primer lugar, necesitamos probar el flujo de datos, es decir, cómo fluyen los datos a través de nuestros servicios, cuáles son las consultas a la base de datos, es decir, qué entrada, salida y transformadores de datos tenemos. Y en la mayoría de los casos, solo necesitamos probar si las operaciones CRUD funcionan correctamente y si la sindicación funciona correctamente y si los puntos finales son correctos, y lo que normalmente hacemos para lograr eso. Por supuesto, en la mayoría de los casos, tenemos pruebas de integración.

¿Y cómo funciona eso? Las pruebas de integración suelen probar el módulo completo, como todo el servicio, pero el servicio no es algo que esté presente por sí mismo, es algo que se comunica con otros módulos como una base de datos o un repositorio de datos o algún modelo de sindicación, entre otras cosas. Por eso, para probarlo, necesitamos simular algunas dependencias. Y cuando hicimos eso y la prueba funciona correctamente, ¿qué hacemos a continuación? Actualizamos el código, agregamos nuevas funcionalidades. ¿Y qué necesitamos hacer después? Necesitamos actualizar las dependencias simuladas, para que la prueba siga funcionando. ¿Y qué más? Sí, necesitamos actualizar las dependencias simuladas una y otra vez, y otra vez, y otra vez, y otra vez.

Realmente me enfrenté a eso. Teníamos una prueba realmente grande, importante y súper mega crítica sobre algún proceso de exportación. Y cada vez que cambiábamos algo mínimo en el código de exportación, necesitábamos reescribir completamente toda la prueba. Eso fue malo. Entonces, ¿cómo podría verse normalmente la prueba de integración con todas las simulaciones? En realidad, es una gran cantidad de diferentes tipos de funciones de simulación, como se muestra en las diapositivas. A veces simulamos todo el módulo, a veces simulamos solo una función. Y por supuesto, cuando algo cambia en la función, especialmente en el último ejemplo aquí, la función de actualización cambió, y su salida cambió. Incluso el formato de salida, que era un objeto, se convirtió en un simple número. Así que necesitábamos actualizar la simulación. Y eso realmente fue molesto porque pasamos mucho tiempo solo para mantener las pruebas. Pero debería ser al revés, es decir, las pruebas deberían ahorrar tiempo en el desarrollo. Entonces, ¿hay alguna alternativa de cómo podemos proceder para que todo el proceso sea más fácil para nosotros como desarrolladores? Básicamente, mi receta para eso fueron las pruebas de extremo a extremo.

Discutimos con el equipo, vale, tenemos el framework Nest.js. Tiene muchas capacidades de pruebas. ¿Por qué no lo usamos para pruebas de extremo a extremo? ¿Y qué es la prueba de extremo a extremo cuando hablamos de la API? Es cuando inicias toda la API, como todo el servicio de nodo en tu entorno de pruebas, y lo pruebas punto por punto.

En esta diapositiva, puedes ver cómo podría ser la inicialización de la API de Nest. Creas un módulo de pruebas, lo inicializas, creas la aplicación de Nest. Al final, debes cerrarlo y, por supuesto, puedes sobrescribir lo que quieras. Por ejemplo, en Nest, usamos los llamados guardias para la autenticación. Aquí, podemos anularlo, inicializarlo y cerrarlo al final cuando todas las pruebas hayan pasado. La simulación del guardia de autenticación es algo bastante simple, que solo escribes una vez y usas en todas partes. Es realmente algo tan simple.

Y así es como se vería toda la prueba. Literalmente, haces una solicitud, haces una solicitud POST o GET a algún punto final específico, para alguna URL específica. Y en este ejemplo, como es POST, puedes enviar detalles de alguien, como qué tipo de proyecto debemos agregar. Y puedes esperar, como aquí en la última línea, puedes esperar algún tipo de código, como que debería devolver 201. Lo que significa creado exitosamente. Y también puedes hacer una solicitud GET y también formar alguna URL, enviar solicitudes, esperar algún código. Y también esperar alguna respuesta. Y verificar que las propiedades de la respuesta sean correctas.

¿Qué quiero decir? Así que los pros y los contras. Los pros, fáciles de corregir, fáciles de modificar y pruebas de todo el flujo de trabajo. Y como puedes ver aquí mismo, toda la prueba es muy legible y también es una fuente adicional de documentación para tu API. Pero, por supuesto, también hay algunos contras y aspectos negativos. Puede llevar tiempo escribir la versión inicial de esta prueba porque en algunos casos necesitas preparar los datos. Por supuesto, cuando solo tienes una API rudimentaria, puedes usar solo solicitudes GET o POST para crear datos y asegurarte de que se creen. Pero en algunos casos, necesitas preparar los datos en una base de datos y esta base de datos mínima debe ejecutarse en algún lugar en un servicio de integración continua. Y solo para ti tenemos un truco realmente especial, muy pequeño. A veces, en mi experiencia, solo una vez. Pero necesitábamos falsificar la fecha. Preparé algunos datos y debo asegurarme de que estos datos se creen con esta fecha actual. Y generalmente lo hacíamos así. Pero en algún código realmente usamos no solo la función now, sino también construct. Y hay una solución un poco más completa de cómo simular la fecha tanto para now como para el constructor. Así que toma una captura de pantalla, es un truco muy útil, nos vemos más tarde.

Y aquí está el enlace a mis diapositivas, mi sitio web y mi documentación, que me inspiraron para todo eso. Entonces, como resumen, haz pruebas. Realmente es algo genial cuando haces pruebas. Y las pruebas de extremo a extremo hacen que los cambios sean más rápidos y puedes cubrir todo el flujo de trabajo con las últimas simulaciones y ser mucho más feliz. ¡Nos vemos, chicos!