Desafíos a la hora de probar aplicaciones sin servidor

Cuando utilice emuladores y llamadas simuladas para realizar pruebas de una aplicación sin servidor en el escritorio local, es posible que experimente incoherencias en las pruebas a medida que el código avance de un entorno a otro en la canalización de CI/CD. Es posible que las pruebas unitarias para validar la lógica empresarial de la aplicación en el escritorio no incluyan o representen con precisión los aspectos críticos de los servicios en la nube. Las pruebas completas no se pueden realizar localmente de forma aislada. Requieren verificar los permisos y las configuraciones de varios servicios.

En las siguientes secciones, se describen los desafíos que puede experimentar al implementar una estrategia de pruebas en la nube.

Ejemplo: la función de Lambda crea un bucket de S3

Si la lógica de una función de Lambda depende de la creación de un bucket de S3, una prueba completa debería confirmar que se llamó a Amazon S3 y que el bucket se creó correctamente. En una configuración de prueba simulada, puede simular una respuesta correcta y, potencialmente, agregar un caso de prueba para gestionar una respuesta de error. En un escenario de pruebas de emulación, es posible que se llame a la CreateBucketAPI, pero la identidad que realiza la llamada no se originará en el servicio Lambda que asume una función y, en su lugar, se utilizará una autenticación de marcador de posición; esta suele ser su función o identidad de usuario más permisiva.

Lo más probable es que las configuraciones de simulación y emulación analizadas anteriormente sirvan para probar qué hará la función de Lambda si llama de forma correcta (o sin éxito) a Amazon S3. Sin embargo, esas pruebas no registrarán si la función de Lambda es capaz de crear de forma correcta el bucket, dada la configuración de la función. Es probable que esta configuración esté representada por una infraestructura como código (IaC) para productos y servicios como Terraform o Terraform. AWS CloudFormation AWS SAM HashiCorp Un posible problema es que el rol que se asigna a la función no tenga una política adjunta que permita la acción s3:CreateBucket y, por lo tanto, la función falle cada vez que se implemente en un entorno de nube.

Ejemplo: una función de Lambda que procesa mensajes de una cola de Amazon SQS

Si una cola de Amazon SQS es el origen de una función de Lambda, una prueba completa debería comprobar que la función de Lambda se invoca correctamente cuando se coloca un mensaje en una cola. Las pruebas de emulación y simulación generalmente se configuran para ejecutar el código de la función de Lambda directamente y para simular la integración de Amazon SQS pasando una carga de eventos JSON (o un objeto deserializado) como entrada del controlador de funciones.

Las pruebas locales que simulan la integración de Amazon SQS comprobarán qué hará la función de Lambda cuando Amazon SQS la llame con una carga determinada, pero no se asegurarán de que Amazon SQS invoque de forma correcta la función de Lambda cuando se implemente en un entorno de nube.

Algunos ejemplos de problemas de configuración que pueden surgir con Amazon SQS y Lambda son los siguientes:

• El tiempo de espera de visibilidad de Amazon SQS es demasiado bajo, lo que provoca varias invocaciones cuando solo se tiene prevista una.

• El rol de ejecución de la función de Lambda no permite leer los mensajes de la cola (a través de sqs:ReceiveMessage, sqs:DeleteMessage o sqs:GetQueueAttributes).

• El evento de ejemplo que se pasa a la función de Lambda supera la cuota de tamaño de los mensajes de Amazon SQS. Por lo tanto, la prueba no es válida porque Amazon SQS nunca podrá enviar un mensaje de ese tamaño.

Como se muestra en estos ejemplos, es probable que las pruebas que cubren la lógica empresarial, pero no las configuraciones entre los servicios en la nube, arrojen resultados poco fiables.