Prácticas recomendadas para probar aplicaciones sin servidor

Las siguientes secciones describen las prácticas recomendadas para lograr una cobertura efectiva al probar aplicaciones sin servidor.

Priorice las pruebas en la nube

Para aplicaciones bien diseñadas, puede emplear una variedad de técnicas de prueba para satisfacer una variedad de requisitos y condiciones. Sin embargo, en función de las herramientas actuales, recomendamos que se centre en las pruebas en la nube en la medida de lo posible. Si bien las pruebas en la nube pueden generar latencia para los desarrolladores, aumentar los costos y, a veces, requerir inversiones en DevOps controles adicionales, esta técnica proporciona la cobertura de prueba más confiable, precisa y completa.

Debe tener acceso a entornos aislados en los que realizar las pruebas. Lo ideal es que cada desarrollador tenga una AWS cuenta dedicada para evitar cualquier problema con la denominación de los recursos que puedan surgir cuando varios desarrolladores que trabajan en el mismo código intenten implementar o invocar llamadas a la API en recursos que tienen nombres idénticos. Estos entornos deben configurarse con alertas y controles apropiados para evitar gastos innecesarios. Por ejemplo, puede limitar el tipo, el nivel o el tamaño de los recursos que se pueden crear y configurar alertas por correo electrónico cuando los costos estimados superen un umbral determinado.

Si tienes que compartir una sola AWS cuenta con otros desarrolladores, los procesos de prueba automatizados deberían asignar nombres a los recursos de forma que sean únicos para cada desarrollador. Por ejemplo, los scripts de actualización o los archivos de configuración TOML que provocan que los comandos AWS SAM CLI sam deploy o sam sync puedan especificar automáticamente un nombre de pila que incluya el nombre de usuario del desarrollador local.

Las pruebas en la nube son valiosas para todas las fases de las pruebas, incluidas las pruebas unitarias, las pruebas de integración y end-to-end las pruebas.

Utilizar simulaciones si es necesario

Los marcos simulados son una herramienta valiosa para escribir pruebas unitarias rápidas. Son muy útiles cuando las pruebas abarcan una lógica empresarial interna compleja, como cálculos o simulaciones matemáticas o financieras. Busque pruebas unitarias que tengan una gran cantidad de casos de prueba o variaciones de entradas, en los que las entradas no cambien el patrón ni el contenido de las llamadas a otros servicios en la nube. La creación de pruebas simuladas para estos escenarios puede mejorar los tiempos de iteración de los desarrolladores.

El código que abarcan las pruebas unitarias que utilizan pruebas simuladas también debe incluirse en las pruebas en la nube. Esto es necesario porque las simulaciones siguen ejecutándose en el ordenador portátil o en el equipo de compilación de un desarrollador y es posible que el entorno esté configurado de forma diferente de como lo estaría en la nube. Por ejemplo, el código puede incluir funciones de Lambda que utilizan más memoria o requieren más tiempo del que Lambda está configurado para asignar cuando se ejecuta con ciertos parámetros de entrada. O bien, el código puede incluir variables de entorno que no están configuradas de la misma manera (o no están configuradas en absoluto) y las diferencias pueden provocar que el código se comporte de manera diferente o que falle.

No utilice simulaciones de servicios en la nube para validar la implementación adecuada de esas integraciones de servicios. Si bien puede ser aceptable simular un servicio en la nube cuando se prueban otras funciones, conviene probar las llamadas al servicio en la nube para validar la configuración y la implementación funcional correctas.

Las simulaciones pueden agregar valor a las pruebas unitarias, especialmente cuando se prueban un gran número de casos con frecuencia. Este beneficio se reduce en el caso de las pruebas de integración, ya que el nivel de esfuerzo necesario para implementar los simulacros necesarios aumenta con el número de puntos de conexión. End-to-endEn las pruebas no se deben utilizar simulaciones, ya que estas pruebas suelen tratar con estados y lógicas complejas que no se pueden simular fácilmente con marcos simulados.

Evitar el uso de emuladores

Los emuladores pueden resultar útiles para algunos casos de uso. Por ejemplo, un equipo de desarrollo puede tener un acceso limitado, discontinuo o lento a Internet. En este caso, realizar pruebas en un emulador podría ser la única forma de iterar el código con fiabilidad antes de trasladarlo a un entorno de nube.

En la mayoría de los demás casos, utilice los emuladores con moderación. Cuando utilizas un emulador, puede resultar difícil innovar e incluir nuevas funciones de AWS servicio en las pruebas hasta que el proveedor de la emulación publique una actualización que ofrezca paridad de funciones. La compra y configuración de emuladores para varios sistemas de desarrollo y equipos de compilación requiere gastos iniciales y continuos. Además, muchos servicios en la nube no tienen emuladores disponibles y la selección de una estrategia de pruebas de emulación impedirá el uso de esos servicios (lo que generará soluciones alternativas potencialmente más caras) o producirá código y configuraciones que no hayan sido probados de forma correcta.

Cuando sea necesario realizar pruebas de emulación, aproveche las pruebas en la nube en la medida de lo posible para asegurarse de que se hayan implementado las configuraciones en la nube adecuadas y probar las interacciones con otros servicios en la nube que solo se puedan simular o imitar en un entorno emulado.

Si es necesario, las pruebas de emulación pueden brindar información para las pruebas unitarias. Es posible que también estén disponibles algunos tipos de end-to-end pruebas y pruebas de integración, según las características y la paridad de comportamiento del software de emulación.

Acelerar los bucles de retroalimentación

Cuando realice pruebas en la nube, utilice herramientas y técnicas para acelerar los bucles de retroalimentación sobre el desarrollo. Por ejemplo, utilice AWS SAM Accelerate y el modo de vigilancia de AWS CDK para reducir el tiempo que se tarda en enviar modificaciones de código a un entorno de nube. Los ejemplos del repositorio GitHub Serverless Test Samples exploran algunas de estas técnicas.

También recomendamos que cree y pruebe los recursos de nube del equipo local lo antes posible durante el desarrollo, no solo después de comprobar el control de origen. Esta práctica permite una exploración y experimentación más rápidas a la hora de desarrollar soluciones. Además, la automatización de la implementación desde un equipo de desarrollo ayuda a descubrir los problemas de configuración de la nube con mayor rapidez y reduce el esfuerzo desperdiciado en actualizar y modificar autorizaciones del control de origen.