Cómo realizar pruebas de funciones y aplicaciones sin servidor

Para probar las funciones sin servidor, se utilizan tipos y técnicas de prueba tradicionales, pero también se debe considerar la posibilidad de probar las aplicaciones sin servidor en conjunto. Las pruebas basadas en la nube proporcionan la medida más precisa de la calidad tanto de las funciones como de las aplicaciones sin servidor.

Una arquitectura de aplicaciones sin servidor incluye servicios administrados que proporcionan las funcionalidades críticas de las aplicaciones mediante llamadas a la API. Por este motivo, el ciclo de desarrollo debe incluir pruebas automatizadas que verifiquen las funcionalidades cuando la función y los servicios interactúen.

Si no crea pruebas basadas en la nube, pueden surgir problemas debido a las diferencias entre su entorno local y el entorno implementado. El proceso de integración continua debe ejecutar pruebas con un conjunto de recursos aprovisionados en la nube antes de promover el código al siguiente entorno de implementación, como el control de calidad, el ensayo o la producción.

Siga leyendo esta breve guía para obtener información sobre las estrategias de prueba para aplicaciones sin servidor, o visite el repositorio de ejemplos de pruebas sin servidor a fin de profundizar en ejemplos prácticos y específicos para el lenguaje y el tiempo de ejecución de su elección.

Para las pruebas sin servidor, sigue escribiendo pruebas unitarias, de integración e integrales.

Resultados empresariales específicos

La configuración para probar soluciones sin servidor puede llevar más tiempo. Debe verificar las interacciones basadas en eventos entre los servicios. Tenga en cuenta estos motivos empresariales prácticos al leer esta guía:

La calidad de una aplicación depende de probar muchos escenarios. Tenga en cuenta sus escenarios empresariales y automatice las pruebas para ejecutarlas en los servicios en la nube. Esto aumenta la calidad de su aplicación.

Los errores y problemas de configuración cuestan menos si se detectan en una fase temprana del ciclo de desarrollo. Los problemas que no se detectan hasta la fase de producción requieren más esfuerzo y más personal para solucionarlos.

Una buena estrategia de pruebas sin servidor mejora la calidad del software y acelera las iteraciones. Verifica que las aplicaciones y funciones de Lambda funcionen como se espera en la nube.

Qué se debe probar

Recomendamos adoptar una estrategia de pruebas que pruebe los comportamientos de los servicios administrados, la configuración de la nube, las políticas de seguridad y la integración con el código. Las pruebas de comportamiento, también conocidas como pruebas de caja negra, verifican que un sistema funcione como se espera sin conocer los aspectos internos.

En la arquitectura tradicional basada en servidores, los equipos suelen probar solo el código que se ejecuta en el servidor de aplicaciones. Consideran que otros componentes, servicios o dependencias son externos y que quedan fuera del ámbito.

Las aplicaciones sin servidor consisten en pequeñas unidades de trabajo. Entre los ejemplos se incluyen las funciones de Lambda que recuperan productos de una base de datos, procesan elementos de una cola o cambian el tamaño de una imagen almacenada. Cada componente se ejecuta en su propio entorno. Los equipos administran muchas de estas pequeñas unidades en una sola aplicación.

Algunas funcionalidades pueden gestionarse por completo mediante servicios administrados, como Amazon S3, o crearse sin código personalizado. No es necesario probar estos servicios administrados. Sin embargo, debe probar cómo se integra su código con ellos.

Cómo efectuar las pruebas sin servidor

Probablemente sepa cómo probar las aplicaciones implementadas localmente. Escriba pruebas con código en su escritorio o dentro de contenedores. Por ejemplo, puede llamar a un servicio web local y, a continuación, comprobar la respuesta.

Las soluciones sin servidor usan el código de funciones y los servicios administrados basados en la nube, como colas, bases de datos, buses de eventos y sistemas de mensajería. Todos estos componentes se conectan a través de una arquitectura basada en eventos, en la que los mensajes, denominados eventos, fluyen de un recurso a otro. Algunas interacciones son síncronas, como un servicio web que devuelve resultados de forma inmediata.

Otras son asíncronas, como incluir elementos en una cola o iniciar un paso del flujo de trabajo. Su estrategia de pruebas debe incluir ambos tipos y probar las interacciones entre los servicios. En el caso de las interacciones asíncronas, es posible que necesite detectar efectos secundarios en los componentes posteriores que no sean visibles de inmediato.

No se puede replicar completamente un entorno en la nube de forma local. Esto incluye colas, tablas de bases de datos, buses de eventos y políticas de seguridad. Las diferencias entre los entornos locales y en la nube causan problemas. Estas diferencias aumentan el tiempo de reproducción y corrección de errores.

En las aplicaciones sin servidor, los componentes existen completamente en la nube. Es necesario realizar pruebas con el código y los servicios de la nube para desarrollar características y corregir los errores.

Técnicas de pruebas

Es probable que su estrategia de pruebas incluya una combinación de técnicas. Utilice pruebas interactivas rápidas para depurar las funciones en la consola. Escriba pruebas unitarias automatizadas para comprobar la lógica empresarial. Verifique las llamadas a los servicios externos con simulaciones. También puede realizar pruebas con emuladores que imitan un servicio.

Pruebas en la nube

Las pruebas en la nube son valiosas para todas las fases de las pruebas: pruebas unitarias, pruebas de integración y pruebas integrales. Las pruebas que se ejecutan con código y servicios basados en la nube proporcionan la medida más precisa de la calidad del código.

Una forma sencilla de ejecutar una función de Lambda en la nube es con un evento de prueba en la Consola de administración de AWS. Un evento de prueba es una entrada JSON a su función. Si la función no requiere una entrada, el evento puede ser un documento JSON vacío ({}). La consola proporciona ejemplos de eventos para muchas integraciones de servicios. Puede compartir eventos con su equipo para facilitar las pruebas.

Aprenda a depurar una función de ejemplo en la consola.

Los ejemplos de automatización de pruebas están disponibles en el repositorio de ejemplos de pruebas sin servidor. La siguiente línea de comandos ejecuta un ejemplo de prueba de integración automática de Python:

python -m pytest -s tests/integration -v

Aunque la prueba se ejecuta de forma local, interactúa con los recursos basados en la nube. Estos recursos se han implementado mediante la herramienta de la línea de comandos de AWS SAM y AWS Serverless Application Model. El código de prueba recupera primero las salidas de la pila implementada, como el punto de conexión de la API, el ARN de la función y el rol de seguridad.

A continuación, envía una solicitud al punto de conexión de la API. La respuesta contiene una lista de buckets de Amazon S3. Esta prueba se ejecuta con recursos basados en la nube para verificar que estén implementados, protegidos y funcionando.

========================= test session starts =========================
      platform darwin -- Python 3.10.10, pytest-7.3.1, pluggy-1.0.0
      -- /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda/venv/bin/python
      cachedir: .pytest_cache
      rootdir: /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda
      plugins: mock-3.10.0
      collected 1 item                                                                                                        

      tests/integration/test_api_gateway.py::TestApiGateway::test_api_gateway 

      --> Stack outputs:

        HelloWorldApi
        = https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

        PythonTestDemo
        = arn:aws:lambda:us-east-2:123456789012:function:testing-apigw-lambda-PythonTestDemo-iSij8evaTdxl
        > Hello World Lambda Function ARN

        PythonTestDemoIamRole
        = arn:aws:iam::123456789012:role/testing-apigw-lambda-PythonTestDemoRole-IZELQQ9MG4HQ
        > Implicit IAM Role created for Hello World function

      --> Found API endpoint for "testing-apigw-lambda" stack...
      --> https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
      API Gateway response:
      amplify-dev-123456789-deployment|myapp-prod-p-loggingbucket-123456|s3-java-bucket-123456789
      PASSED

      ========================= 1 passed in 1.53s ========================= 
      

Para el desarrollo de aplicaciones nativas en la nube, las pruebas en la nube ofrecen las siguientes ventajas:

Las pruebas en la nube tienen algunas desventajas. Las implementaciones en la nube suelen tardar más que las implementaciones de escritorio locales.

Herramientas como AWS Serverless Application Model (AWS SAM) Accelerate, el modo de vigilancia de AWS Cloud Development Kit (AWS CDK y SST (de terceros) reducen esta latencia. Estas herramientas supervisan su infraestructura y código y, a continuación, implementan automáticamente actualizaciones en su entorno en la nube.

A diferencia de las pruebas locales, las pruebas en la nube utilizan recursos que pueden generar costos. Los entornos de pruebas aislados pueden agregar trabajo a sus equipos de DevOps, especialmente en organizaciones con controles de cuentas estrictos. Aun así, el tiempo que los desarrolladores dedican a configurar un entorno local complejo puede costar más que utilizar entornos en la nube desechables creados con herramientas de infraestructura como código.

Las pruebas en la nube, incluso teniendo en cuenta estas consideraciones, siguen siendo la mejor manera de garantizar la calidad de sus soluciones sin servidor.

Pruebas con simulaciones

Las pruebas con simulaciones son una técnica en la que se crean objetos de reemplazo en el código para simular el comportamiento de un servicio en la nube.

Por ejemplo, puede escribir una prueba que utilice una simulación del servicio Amazon S3. La simulación devuelve una respuesta establecida cada vez que se llama al método CreateObject. No llama a Amazon S3 ni a ningún otro punto de conexión de servicio.

Los marcos de simulación suelen generar objetos simulados automáticamente. Algunos marcos son genéricos. Otros se centran en los SDK de AWS , como Moto, una biblioteca de Python para simular servicios de AWS .

Los objetos simulados difieren de los emuladores. Los desarrolladores crean simulaciones como parte del código de prueba. Los emuladores son aplicaciones independientes que presentan la misma funcionalidad que los sistemas que imitan.

Entre las ventajas de utilizar simulaciones se incluyen las siguientes:

Las pruebas simuladas tienen las siguientes desventajas:

Probar localmente con la CLI de AWS SAM

Use la CLI de AWS SAM para probar sus funciones en contenedores de Docker mediante el mismo entorno de tiempo de ejecución que AWS Lambda. Puede probar la lógica de las funciones y el procesamiento de eventos a nivel local sin necesidad de implementarlos en la nube. Si la función realiza llamadas a la API a otros Servicios de AWS, esas llamadas llegan a recursos de AWS reales.

Entre las ventajas de realizar pruebas con contenedores locales se incluyen las siguientes:

Las pruebas con contenedores locales tienen las siguientes limitaciones:

Pruebas con emulación

Los emuladores son aplicaciones que se ejecutan a nivel local y que imitan los servicios de AWS al proporcionar API y valores de retorno similares. LocalStack es una popular herramienta de emulación que proporciona un entorno de desarrollo local completo para realizar pruebas de las integraciones de servicios.

LocalStack es un emulador de AWS en la nube que se puede usar para probar aplicaciones sin servidor de forma local. Puede probar las funciones de Lambda que se integran con servicios como DynamoDB, Amazon S3 y Amazon SQS sin conectarse a los servicios de AWS reales. Puede usar LocalStack en AWS Toolkit for VS Code.

Entre las ventajas de realizar pruebas con emuladores se incluyen las siguientes:

Las pruebas con emuladores tienen las siguientes desventajas:

Prácticas recomendadas

En las siguientes secciones, se proporcionan recomendaciones para realizar pruebas satisfactorias de aplicaciones sin servidor.

Puede encontrar ejemplos prácticos de pruebas y automatización de pruebas en el repositorio de ejemplos de pruebas sin servidor.

Priorice las pruebas en la nube

Las pruebas en la nube ofrecen la cobertura de pruebas más confiable, precisa y completa. Al realizar pruebas en el contexto de la nube, se comprueban de manera exhaustiva no solo la lógica empresarial, sino también las políticas de seguridad, las configuraciones de servicios, las cuotas y las firmas de API y los valores devueltos más actualizados.

Estructure su código para que sea fácil de probar

Simplifique sus pruebas y funciones de Lambda al separar el código específico de Lambda de su lógica empresarial principal.

El controlador de la función de Lambda debe ser un adaptador compacto que tome los datos de los eventos y que transmita solo los detalles importantes a sus métodos de lógica empresarial. Con esta estrategia, puede empaquetar pruebas exhaustivas en torno a su lógica empresarial sin preocuparse por los detalles específicos de Lambda. Las funciones de AWS Lambda de no deberían requerir la configuración de un entorno complejo o una gran cantidad de dependencias para crear e inicializar el componente que se está probando.

En términos generales, debe escribir un controlador que extraiga y valide los datos de los objetos de evento y contexto entrantes y, a continuación, envíe esa entrada a los métodos que ejecuten su lógica empresarial.

Acelere los ciclos de retroalimentación del desarrollo

Existen herramientas y técnicas para acelerar los ciclos de retroalimentación del desarrollo. Por ejemplo, tanto AWS SAM Accelerate como el modo de vigilancia de AWS CDK reducen el tiempo necesario para actualizar los entornos de nube.

Los ejemplos del repositorio de ejemplos de pruebas sin servidor de GitHub exploran algunas de estas técnicas.

También recomendamos que cree y pruebe los recursos en la nube lo antes posible durante el desarrollo, no solo después de comprobar el control del 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 lo ayuda a descubrir los problemas de configuración de la nube con mayor rapidez y reduce el esfuerzo desperdiciado en las actualizaciones y los procesos de revisión del código.

Céntrese en las pruebas de integración

Cuando se crean aplicaciones con Lambda, se recomienda probar los componentes juntos.

Las pruebas que se ejecutan en dos o más componentes arquitectónicos se denominan pruebas de integración. El objetivo de las pruebas de integración es comprender no solo cómo se ejecuta el código en todos los componentes, sino también cómo se comporta el entorno que aloja el código. Las pruebas integrales son tipos especiales de pruebas de integración que verifican los comportamientos de toda una aplicación.

Para crear pruebas de integración, implemente la aplicación en un entorno de nube. Esto se puede hacer desde un entorno local o mediante una canalización de CI/CD. A continuación, escriba pruebas para ejercitar el sistema bajo prueba (SUT) y validar el comportamiento esperado.

Por ejemplo, el sistema bajo prueba puede ser una aplicación que utilice API Gateway, Lambda y DynamoDB. Una prueba puede realizar una llamada HTTP sintética a un punto de conexión de API Gateway y validar que la respuesta haya incluido la carga esperada. Esta prueba valida que el código de AWS Lambda es correcto y que cada servicio está configurado de forma adecuada para gestionar la solicitud, incluidos los permisos de IAM entre ellos. Además, puede diseñar la prueba para escribir registros de varios tamaños a fin de verificar que sus cuotas de servicio, como el tamaño máximo de registro en DynamoDB, están configuradas correctamente.

Cree entornos de pruebas aislados

Las pruebas en la nube suelen requerir entornos de desarrollo aislados, de modo que las pruebas, los datos y los eventos no se superpongan.

Un enfoque consiste en proporcionar a cada desarrollador una cuenta de AWS dedicada. Esto evita conflictos con la nomenclatura de los recursos que pueden ocurrir cuando varios desarrolladores que trabajan en una base de código compartida intentan implementar recursos o invocar una API.

Los procesos de prueba automatizados deben crear recursos con nombres únicos para cada pila. Por ejemplo, puede configurar scripts o archivos de configuración TOML para que los comandos sam deploy o sam sync de la CLI de AWS SAM especifiquen automáticamente una pila con un prefijo único.

En algunos casos, los desarrolladores comparten una cuenta de AWS. Esto puede deberse a que hay recursos en su pila que son costosos de operar o de aprovisionar y configurar. Por ejemplo, se puede compartir una base de datos para facilitar la configuración y la introducción de datos de forma adecuada.

Si los desarrolladores comparten una cuenta, debe establecer límites para identificar la propiedad y eliminar la superposición. Una forma de hacerlo consiste en poner un prefijo a los nombres de las pilas con los ID de usuario de los desarrolladores. Otro enfoque popular es configurar pilas basadas en ramas de código. Con los límites de las ramas, los entornos están aislados, pero los desarrolladores pueden seguir compartiendo recursos, como una base de datos relacional. Este enfoque es una práctica recomendada cuando los desarrolladores trabajan en más de una rama a la vez.

Las pruebas en la nube son valiosas para todas las fases de las pruebas, incluidas las pruebas unitarias, las pruebas de integración y las pruebas integrales. Mantener un aislamiento adecuado es esencial, pero aun así querrá que su entorno de control de calidad se parezca lo más posible a su entorno de producción. Por este motivo, los equipos agregan procesos de control de cambios para los entornos de control de calidad.

En los entornos de preproducción y producción, los límites se suelen establecer a nivel de cuenta para aislar las cargas de trabajo de los problemas de vecinos ruidosos e implementar controles de seguridad con privilegios mínimos a fin de proteger los datos confidenciales. Las cargas de trabajo tienen cuotas. No querrá que sus pruebas consuman las cuotas asignadas a la producción (vecinos ruidosos) ni tengan acceso a los datos de los clientes. Las pruebas de carga son otra actividad que debe aislar de la pila de producción.

En todos los casos, los entornos deben configurarse con alertas y controles 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.

Utilice simulaciones para una lógica empresarial aislada

Los marcos simulados son una herramienta valiosa para escribir pruebas unitarias rápidas. Son especialmente útiles cuando las pruebas cubren 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 entrada, en las que esas entradas no cambien el patrón ni el contenido de las llamadas a otros servicios en la nube.

El código que se incluye en las pruebas unitarias con simulaciones también debe incluirse en las pruebas en la nube. Esto se recomienda porque un entorno de equipo portátil o de compilación para desarrolladores puede configurarse de forma diferente a un entorno de producción en la nube. Por ejemplo, las funciones de Lambda pueden utilizar más memoria o tiempo del asignado cuando se ejecutan 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.

El beneficio de las simulaciones es menor en las pruebas de integración, ya que el nivel de esfuerzo para implementar las simulaciones necesarias aumenta con la cantidad de puntos de conexión. Las pruebas integrales no 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.

Por último, evite utilizar servicios en la nube simulados para validar el despliegue correcto de las llamadas de servicio. En su lugar, realice llamadas al servicio de nube en la nube para validar el comportamiento, la configuración y el despliegue funcional.

Use emuladores con moderación

Los emuladores pueden resultar útiles para algunos casos de uso, por ejemplo, para un equipo de desarrollo con acceso a Internet limitado, poco fiable o lento. Sin embargo, en la mayoría de los casos, opte por utilizar los emuladores con moderación.

Al evitar los emuladores, puede crear e innovar con las características de servicio más recientes y las API actualizadas. No tiene que esperar a que los proveedores publiquen sus productos para lograr la paridad de características. Reduce los gastos iniciales y continuos de compra y configuración en múltiples sistemas de desarrollo y equipos de compilación. Además, evita el problema de que muchos servicios en la nube simplemente no tienen emuladores disponibles. Una estrategia de pruebas que depende de la emulación imposibilita el uso de esos servicios (lo que podría generar soluciones alternativas más costosas) o produce código y configuraciones que no están bien probados.

Cuando utilice la emulación para realizar pruebas, deberá seguir realizando pruebas en la nube para verificar la configuración y probar las interacciones con los servicios en la nube que solo se pueden simular o imitar en un entorno emulado.

Desafíos al probar de forma local

Cuando utilice emuladores y llamadas simuladas para realizar pruebas 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 prueben con precisión los aspectos críticos de los servicios en la nube.

En los siguientes ejemplos, se muestran casos para tener en cuenta al realizar pruebas locales con simulaciones y emuladores:

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.

Las configuraciones de simulación y emulación comprueban qué hace la función de Lambda si llama a Amazon S3; sin embargo, esas pruebas no verifican que la función de Lambda, tal como está configurada, sea capaz de crear correctamente el bucket de Amazon S3. Debe asegurarse de que el rol asignado a la función tenga una política de seguridad adjunta que permita a la función realizar la acción s3:CreateBucket. De lo contrario, es probable que la función falle cuando se implemente en un entorno en la nube.

Ejemplo: la función de Lambda 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 útil de eventos JSON (o un objeto deserializado) como entrada del controlador de funciones.

Las pruebas locales que simulan la integración de Amazon SQS comprueban qué hace la función de Lambda cuando Amazon SQS la llama con una carga útil determinada, pero no verifican que Amazon SQS invoque correctamente la función de Lambda cuando se implementa en un entorno en la nube.

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

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.

Preguntas frecuentes

Tengo una función de Lambda que realiza cálculos y devuelve un resultado sin llamar a ningún otro servicio. Realmente necesito probarlo en la nube?

Sí. Las funciones de Lambda tienen parámetros de configuración que pueden cambiar el resultado de la prueba. Todo el código de la función de Lambda depende de la configuración del tiempo de espera y la memoria, lo que puede provocar un error en la función si esos ajustes no se configuran correctamente.

Las políticas de Lambda también permiten el registro de salida estándar en Amazon CloudWatch. Incluso si su código no llama directamente a CloudWatch, se necesitan permisos para habilitar el registro. Este permiso obligatorio no se puede burlar ni emular con precisión.

Cómo pueden ayudar las pruebas en la nube a las pruebas unitarias? Si está en la nube y se conecta a otros recursos, ¿no es una prueba de integración?

Definimos las pruebas unitarias como aquellas que funcionan en componentes arquitectónicos de forma aislada, pero esto no impide que las pruebas incluyan componentes que pueden llamar a otros servicios o utilizar alguna comunicación de red.

Muchas aplicaciones sin servidor tienen componentes arquitectónicos que se pueden probar de forma aislada, incluso en la nube. Un ejemplo es una función de Lambda que toma una entrada, procesa los datos y envía un mensaje a una cola de Amazon SQS. Una prueba unitaria de esta función probablemente comprobaría si los valores de entrada dan como resultado que ciertos valores estén presentes en el mensaje en cola.

Considere una prueba que se escribe con el patrón Organizar, Actuar, Afirmar:

Un enfoque de prueba simulada implicaría simular la cola con un objeto simulado en proceso y crear una instancia en proceso de la clase o módulo que contenga el código de la función de Lambda. Durante la fase de afirmación, el mensaje en cola se recuperaría del objeto de la simulación.

En un enfoque basado en la nube, la prueba crearía una cola de Amazon SQS para los fines de la prueba e implementaría la función de Lambda con variables de entorno configuradas para utilizar la cola aislada de Amazon SQS como destino de salida. Tras ejecutar la función de Lambda, la prueba recuperaría el mensaje de la cola de Amazon SQS.

La prueba basada en la nube ejecutaría el mismo código, afirmaría el mismo comportamiento y validaría la corrección funcional de la aplicación. Sin embargo, tendría la ventaja adicional de poder validar la configuración de la función de Lambda: el rol de IAM, las políticas de IAM y la configuración de memoria y tiempo de espera de la función.

Próximos pasos y recursos

Utilice los siguientes recursos para obtener más información y explorar ejemplos prácticos de pruebas.

Despliegue de ejemplo

El repositorio de ejemplos de pruebas sin servidor de GitHub contiene ejemplos concretos de pruebas que siguen los patrones y las prácticas recomendadas que se describen en esta guía. El repositorio contiene código de muestra y tutoriales guiados sobre los procesos de simulación, emulación y prueba en la nube descritos en las secciones anteriores. Utilice este repositorio para ponerse al día con la guía de pruebas sin servidor más reciente de  AWS.

Documentación adicional

Visite Serverless Land para acceder a los blogs, videos y formaciones más recientes sobre tecnologías de AWS sin servidor.

También se recomienda leer las siguientes publicaciones del blog de AWS:

Herramientas