Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
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 disponga de una Cuenta de AWS plantilla específica para evitar los problemas de denominación de los recursos que pueden producirse cuando varios desarrolladores que trabajan en el mismo código intentan 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 versión Cuenta de AWS 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 portátil o en la máquina de compilación del desarrollador, y es posible que el entorno esté configurado de forma diferente a como lo estará en la nube. Por ejemplo, el código puede incluir AWS Lambda funciones que utilizan más memoria o tardan más tiempo del que Lambda está configurado para asignar cuando se ejecuta con determinados parámetros de entrada. O bien, el código puede incluir variables de entorno que no están configuradas de la misma manera (o que no están configuradas en absoluto), y las diferencias pueden provocar que el código se comporte de forma diferente o que se produzca un error.
No utilices simulacros de servicios en la nube para validar la correcta implementación 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.
Los simulacros pueden añadir 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 las simulaciones necesarias 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.
Comprenda las ventajas y desventajas de las pruebas de emulación
Los emuladores pueden ser una opción práctica para casos de uso específicos. Por ejemplo, un equipo de desarrollo con un acceso a Internet limitado, incoherente o lento puede descubrir que las pruebas de emulación son la forma más fiable de iterar el código antes de pasar a un entorno de nube.
En la mayoría de los demás casos, utilice los emuladores de forma selectiva. Cuando dependes en gran medida de un emulador, puede resultar difícil incorporar nuevas funciones de AWS servicio en las pruebas hasta que el proveedor de la emulación publique una actualización que proporcione la paridad de funciones. Los emuladores también requieren una inversión inicial y continua para la instalación y configuración de los sistemas de desarrollo y las máquinas de compilación. Además, muchos servicios en la nube no tienen emuladores disponibles; si se opta por una estrategia que dé prioridad a la emulación, es posible que se impida el uso de esos servicios o que se produzcan códigos y configuraciones que no estén bien comprobados comparándolos con el comportamiento real de los servicios.
Si utilizas las pruebas de emulación, complétalas con pruebas en la nube en la medida de lo posible para comprobar que existen las configuraciones de nube adecuadas y para probar las interacciones con servicios que solo se pueden simular o simular en un entorno emulado.
Las pruebas de emulación pueden proporcionar información rápida para las pruebas unitarias y, según las características y la paridad de comportamiento del software de emulación, también pueden admitir algunas integraciones y pruebas. end-to-end
Supervisa las pruebas a través de los límites naturales
A medida que las aplicaciones sin servidor crecen en más componentes arquitectónicos, surgen límites naturales en torno a los subsistemas, especialmente cuando se siguen las mejores prácticas, como las funciones de un solo propósito y la disociación basada en eventos. Estos límites sirven como puntos de prueba efectivos donde se pueden validar los contratos entre los componentes.
Identifique los límites de la arquitectura
Busque costuras naturales en el diseño de su aplicación:
-
Entre servicios, como una EventBridge regla de Amazon que conecta a un editor con un consumidor
-
En los bordes de la API, como los puntos de enlace de Amazon API Gateway que se encuentran delante de las funciones de Lambda
-
En torno a los flujos de trabajo, como la organización de AWS Step Functions varios servicios
-
En las capas de almacenamiento, como las transmisiones de Amazon DynamoDB, se desencadena el procesamiento descendente
Separe el código Lambda de la lógica empresarial
Simplifique sus pruebas aislando el código Lambda de la lógica empresarial principal. El controlador Lambda debe actuar como un adaptador ligero entre el tiempo de AWS ejecución y la lógica de la aplicación. Debe extraer y validar los datos del evento y, a continuación, delegarlos en una función comprobable que no tenga dependencias de Lambda. Esto hace que su lógica empresarial sea portátil, más fácil de razonar y fácil de probar sin burlarse de los objetos Lambda ni configurar entornos complejos.
Trate los límites como contratos
Realice la prueba en el límite, no a través de él. Valide lo que cruza el límite sin necesidad de utilizar todo el sistema descendente. Estos mismos límites también sirven como ganchos de observabilidad en la producción. Las estructuras arquitectónicas en las que se realizan las pruebas se pueden instrumentar para la supervisión mediante Amazon CloudWatch Logs, AWS X-Ray rastreos y EventBridge eventos.
Utilice arneses de prueba para flujos de trabajo asíncronos
Las aplicaciones sin servidor suelen basarse en patrones asíncronos, en los que los eventos activan el procesamiento, los mensajes fluyen a través de las colas y los flujos de trabajo abarcan varios servicios sin respuestas inmediatas. No puede simplemente invocar una función e inspeccionar un valor devuelto. El resultado puede aparecer más adelante en una base de datos, un flujo de registro u otro servicio.
Un arnés de pruebas consiste en probar la infraestructura que se implementa junto con la aplicación para observar y validar este comportamiento asincrónico. Los arneses de prueba suelen incluir:
-
Detectores de eventos que se suscriben a los mismos eventos que produce tu aplicación
-
Mecanismos de almacenamiento (como tablas de DynamoDB o depósitos de Amazon S3) donde se pueden capturar los resultados de las pruebas
-
Lógica de sondeo en el código de prueba que espera a que aparezcan los resultados esperados
El código de prueba inicia un evento, espera a que se complete el flujo de trabajo y, a continuación, consulta el arnés de pruebas para comprobar que se ha producido el resultado esperado.
A continuación se indican las prácticas recomendadas:
-
Defina claramente SLAs las operaciones asíncronas: establezca cuánto tiempo deben durar los flujos de trabajo y utilícelas como tiempos de espera de sondeo en sus pruebas
-
Utilice identificadores únicos para aislar las pruebas: genere nombres de archivo, mensajes IDs o identificadores de correlación únicos por ejecución de la prueba para evitar interferencias entre las pruebas
-
Implemente una infraestructura de pruebas junto con su aplicación: incluya recursos de pruebas y arneses en sus infrastructure-as-code plantillas para que se mantengan sincronizados a medida que la aplicación evoluciona
-
Limpie los datos de las pruebas después de ejecutarlas: esto evita que se acumulen artefactos de prueba en su entorno de nube
Los arneses de pruebas son especialmente valiosos para las pruebas de integración que validan los flujos de trabajo en varios servicios, end-to-end las pruebas que verifican los recorridos completos de los usuarios y las arquitecturas basadas en eventos en las que los servicios se comunican a través de Amazon EventBridge SNS, Amazon SQS o Amazon Kinesis.
Organice los entornos de nube para aislar a los desarrolladores
Las pruebas en la nube requieren entornos que estén aislados unos de otros. Cuando los desarrolladores compartan una sola cuenta Cuenta de AWS, como una cuenta de desarrollo en equipo, considere la posibilidad de crear una pila de aplicaciones independiente para cada desarrollador o rama de funciones. Esto aísla los recursos, evita conflictos de nombres y evita conflictos de cuotas o problemas de vecinos ruidosos durante las pruebas.
Utilice AWS Systems Manager Parameter Store o herramientas similares para gestionar las configuraciones específicas de las pilas, como los puntos finales de las API y los nombres de las colas. Para lograr una mayor rentabilidad, comparta recursos costosos como los clústeres de Amazon Relational Database Service (Amazon RDS) entre los grupos de desarrolladores y, al mismo tiempo, mantenga los recursos livianos sin servidor (como las funciones de Lambda, las etapas de API Gateway y las tablas de DynamoDB) aislados por pila.
En los sectores regulados, las políticas de seguridad empresarial pueden restringir el acceso de los desarrolladores a los entornos de nube, lo que dificulta la ejecución de pruebas en la nube como parte de un flujo de trabajo de desarrollo local. En estos casos, las pruebas de emulación pueden colmar el vacío entre las simulaciones de pruebas locales y la validación completa en la nube, aunque deberían complementarse con pruebas en la nube siempre que el acceso lo permita.
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 el modo AWS SAM
Acelerar y AWS CDK observar para reducir el tiempo que se tarda en enviar las modificaciones del código a un entorno de nube. Los ejemplos del repositorio GitHub Serverless Test Samples
También le recomendamos que cree y pruebe los recursos en la nube desde su máquina local lo antes posible durante el desarrollo, no solo después de iniciar sesión en el control de código fuente. 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.
