Disenador de Tests de API

El Problema

Las APIs son la columna vertebral de las aplicaciones modernas, pero la mayoria de los equipos solo testean el happy path — request valido entra, respuesta esperada sale. Se pierden requests malformados, casos borde de autenticacion, rate limiting, limites de paginacion, escrituras concurrentes y las docenas de codigos HTTP que deberian testearse. Un solo caso borde de API sin testear puede convertirse en una vulnerabilidad de seguridad o un bug de corrupcion de datos.

El Prompt

Disena una suite de tests de API completa para los siguientes endpoints. Cubre cada forma en que un request puede tener exito, fallar o comportarse inesperadamente.

ESPECIFICACION DE API:
[pega tu spec OpenAPI/Swagger, definicion de ruta, o describe el endpoint]

AUTENTICACION: [ej. Bearer JWT, API key, OAuth 2.0, ninguna]
FRAMEWORK: [ej. Supertest + Jest, httpx + pytest, REST Assured]

Genera tests para cada categoria:

1. **Validacion de Request** — campos faltantes, tipos incorrectos, campos extra, valores limite, payloads SQL/XSS en inputs
2. **Autenticacion y Autorizacion** — token expirado, token faltante, rol incorrecto, token de otro usuario
3. **Schema de Response** — verificar la forma de respuesta para cada codigo de estado (200, 201, 400, 401, 403, 404, 409, 422, 429, 500)
4. **Paginacion y Filtrado** — primera pagina, ultima pagina, resultados vacios, numero de pagina invalido, orden de sort
5. **Idempotencia** — requests POST/PUT duplicados, modificaciones concurrentes, manejo de ETag/If-Match
6. **Rate Limiting** — verificar respuesta 429 y header Retry-After
7. **Negociacion de Contenido** — variaciones de header Accept, manejo de charset

Para cada test incluir el request HTTP completo (metodo, ruta, headers, body) y respuesta esperada (status, headers, forma del body).

Ejemplo de Salida

describe('POST /api/users', () => {
  it('debe retornar 201 con objeto usuario en creacion valida', async () => {
    const res = await request(app).post('/api/users')
      .set('Authorization', `Bearer ${adminToken}`)
      .send({ email: 'nuevo@test.com', name: 'Usuario Test', role: 'member' });
    expect(res.status).toBe(201);
    expect(res.body).toMatchObject({ email: 'nuevo@test.com', role: 'member' });
    expect(res.body.id).toBeDefined();
  });

  it('debe retornar 409 cuando el email ya existe', async () => {
    const res = await request(app).post('/api/users')
      .set('Authorization', `Bearer ${adminToken}`)
      .send({ email: 'existente@test.com', name: 'Duplicado', role: 'member' });
    expect(res.status).toBe(409);
    expect(res.body.error).toContain('ya existe');
  });
});

Cuando Usar

Usar cuando construyes nuevos endpoints de API, cuando escribes tests para una API legacy sin documentar, o antes de abrir una API a consumidores de terceros. Es esencial antes de que cualquier API llegue a produccion — los bugs de API son mas dificiles de arreglar una vez que los clientes dependen del comportamiento.

Tips Pro

• Empezar desde la spec OpenAPI — pegar la spec YAML/JSON y pedir a la IA que genere tests para cada codigo de respuesta documentado.
• Testear bodies de respuesta de error — la mayoria de equipos solo verifican codigos de estado. Asegurar que las respuestas de error incluyan codigos de error legibles por maquina.
• Incluir payloads de seguridad — agregar <script>alert(1)</script> y '; DROP TABLE users; -- en campos string para verificar sanitizacion de input.
• Generar una coleccion Postman — continuar con “Convierte estos tests en un JSON de coleccion Postman” para testing manual y compartir con el equipo.