En el examen AWS DVA-C02, las preguntas sobre pruebas principalmente preguntan: '¿Como pruebas tu codigo localmente antes de desplegarlo?' Como usar entornos reales de AWS cada vez resulta costoso y lento, los desarrolladores prueban localmente primero siempre que sea posible. Veamos los metodos clave.
¿Que es SAM Local Testing?
AWS SAM (Serverless Application Model) es una herramienta que facilita la creacion y el despliegue de aplicaciones serverless como las funciones Lambda. Al instalar el SAM CLI, puedes probar funciones Lambda en tu propio ordenador como si estuvieran ejecutandose en AWS real.
Es como un chef que prueba la comida en la cocina antes de servirla a los clientes — verificas que todo funciona antes de salir en vivo.
Tres comandos SAM local de uso comun:
sam local invoke
Ejecuta una funcion Lambda directamente en tu maquina local. Puedes pasar un archivo de datos de evento de prueba (en formato JSON) junto con el.
sam local start-api
Inicia un servidor local que simula API Gateway en tu ordenador. Puedes enviar solicitudes a una direccion local (por ejemplo, http://localhost:3000) usando un navegador o Postman para probar tus APIs.
sam local generate-event
Genera automaticamente datos JSON de muestra que imitan eventos reales como una carga de archivo a S3, la llegada de un mensaje SQS o una solicitud de API Gateway. Esto te ahorra tener que escribir escenarios de prueba desde cero.
¿Que son los Eventos de Prueba?
Una funcion Lambda no se ejecuta sola — siempre necesita algo que la dispare (un evento). Por ejemplo, puede ejecutarse cuando se sube un archivo a S3 o cuando llega un mensaje a una cola SQS.
Al hacer pruebas, necesitas crear estos eventos tu mismo y pasarselos a la funcion. Cada fuente de evento (S3, SQS, API Gateway, DynamoDB Streams, etc.) tiene su propia estructura de datos JSON unica.
Puedes crear eventos de prueba directamente desde la consola de Lambda, o usar el comando sam local generate-event descrito anteriormente.
Pruebas Unitarias vs Pruebas de Integracion
Pruebas Unitarias
Aislas un pequeño fragmento de codigo (una sola funcion o modulo) y lo pruebas por separado. Los servicios externos como DynamoDB o S3 se reemplazan con versiones Mock (falsas) en lugar de conexiones reales.
Esto es como quitar el motor de un coche y probarlo por separado. Los desarrolladores de Python suelen usar la libreria moto, mientras que los de Node.js usan aws-sdk-mock.
Pruebas de Integracion
Pruebas si multiples servicios realmente funcionan correctamente juntos. Por ejemplo, verificar el flujo completo de Lambda a DynamoDB a S3 en un entorno real.
Stages de API Gateway
Un Stage es una forma de gestionar la misma API en multiples entornos — como desarrollo (dev), staging y produccion (prod). Piensalo como ejecutar versiones separadas de la misma aplicacion: una para desarrolladores, una para pruebas y otra para usuarios reales.
Variables de Stage: Puedes asignar diferentes direcciones de funcion Lambda o endpoints de base de datos a cada stage. El codigo sigue siendo el mismo, pero cada entorno usa su propia configuracion. Canary Releases: Al desplegar una nueva version, primero envias solo una porcion del trafico (por ejemplo, 10%) a la nueva version. Si no aparecen problemas, lo despliegas gradualmente a todos.
Amazon Q Developer
Amazon Q Developer es una herramienta impulsada por IA que ayuda con la escritura de codigo. Soporta generacion automatica de codigo, deteccion de bugs y creacion automatica de codigo de pruebas — como tener un colega desarrollador experimentado sentado a tu lado.
Puntos Clave del Examen
"Probar Lambda localmente" -- sam local invoke
"Simular API Gateway localmente" -- sam local start-api
"Generar JSON de evento de muestra" -- sam local generate-event
"Reemplazar servicios externos con simulaciones" -- Mock API (moto, aws-sdk-mock)
"Configuraciones diferentes por stage" -- variables de stage de API Gateway
"Enviar solo trafico parcial a nueva version" -- Canary release
"Generacion de codigo y pruebas con IA" -- Amazon Q Developer
Prueba unitaria = aislada, usa Mocks / Prueba de integracion = conexiones de servicio reales