Hacer UI Testing con Playwright está...ponele que bien. E2E con APIs es un poquito más copado. Ahora...¿querés sentirte más pro? ¿Qué tal testear funciones Lambda en AWS con Playwright (y un ayudín)?

Las Lambda functions son fáciles de escribir. Lo complicado empieza cuando querés saber si de verdad funcionan en el contexto real: con los permisos correctos, con el trigger adecuado, devolviendo lo que se espera.

Los unit tests no te salvan acá. Lo que necesitás es integration testing. Creeme, lo viví.

En este artículo te muestro cómo testear Lambdas a nivel de integración: invocándolas realmente contra AWS, validando el output con Playwright, y organizando los tests para que sean mantenibles.

Por qué los unit tests no son suficientes para Lambdas

Una Lambda vive en un ecosistema. Se conecta a S3, DynamoDB, SQS, API Gateway o lo que sea que hayas armado. Un unit test mockeado no te va a decir si:

• El rol de IAM tiene los permisos que necesita

• El payload que devuelve tiene la estructura correcta

• La integración con otros servicios funciona como esperás

Para eso necesitás invocar la Lambda de verdad, contra un entorno real (o un sandbox tuyo), y validar lo que sale.

El stack que vamos a usar

Para estos tests usamos dos herramientas:

AWS SDK v3 para invocar la Lambda directamente desde el código de test. Nada de consola, nada de curl: programático y automatizable.

Playwright para los assertions. Sí, Playwright. No solo sirve para UI testing, su API de assertions es sólida, legible, y tiene soporte nativo para async/await que se lleva perfecto con las llamadas a AWS.

Estructura básica de un integration test de Lambda

import { LambdaClient, InvokeCommand } from "@aws-sdk/client-lambda";
import { expect } from "@playwright/test";

const client = new LambdaClient({ region: "us-east-1" });

async function invocarLambda(payload) {
  const command = new InvokeCommand({
    FunctionName: "mi-lambda-de-ejemplo",
    Payload: JSON.stringify(payload),
  });

  const response = await client.send(command);
  const body = JSON.parse(Buffer.from(response.Payload).toString());
  return body;
}

// El test
const resultado = await invocarLambda({ userId: "abc123" });

await expect(resultado.statusCode).toBe(200);
await expect(resultado.body).toHaveProperty("nombre");

Simple, directo, y sin mocks que te mientan.

Agrupando los tests

Cuando empezás a tener varios tests para la misma Lambda, o para diferentes Lambdas de un mismo flujo, el agrupamiento importa.

Podés organizar por función, por flujo de negocio, o por tipo de escenario (happy path, errores, edge cases). La clave es que cuando algo falla, sepas exactamente qué parte del sistema rompió.

test.describe("Lambda: procesarPedido", () => {
  test("devuelve 200 con pedido válido", async () => { ... });
  test("devuelve 400 si falta el campo producto", async () => { ... });
  test("devuelve 500 si DynamoDB no responde", async () => { ... });
});

Ejecución: paralela, con variables de entorno, y repetible

Los integration tests contra AWS tienen que poder correr en cualquier momento sin depender de que alguien configuró algo a mano. Eso significa:

• Variables de entorno para region, credenciales y nombre de función

• Posibilidad de correr en paralelo (Playwright lo maneja solo si los tests son independientes)

• Cleanup después de cada test si creaste recursos

Esto es solo el punto de partida

Acá vimos la base. Pero cuando empezás a testear flujos reales, Lambdas que leen de S3, escriben en DynamoDB, o forman parte de un Step Function, la complejidad sube rápido.

En mi curso AWS para Testers entramos en todo esto en profundidad: setup del entorno, estrategia de testing para arquitecturas serverless, y cómo integrar esto en un pipeline de CI/CD.